Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[clang][integrated-as] "expected absolute expression" diffing symbols #53728

Closed
nickdesaulniers opened this issue Feb 10, 2022 · 6 comments
Closed
Labels
bug Indicates an unexpected problem or unintended behavior llvm:asmparser

Comments

@nickdesaulniers
Copy link
Member

.text
start:
  nop
end:
.if (end - start) == 0
.err
.endif
$ clang test-label.s -c
$
.text
.set start, .;
  nop
.set end, .;
.if (end - start) == 0
.err
.endif
$ clang test-symbol.s
test-symbol.s:6:5: error: expected absolute expression
.if (end - start) == 0
    ^
test-symbol.s:7:1: error: .err encountered
.err
^
$ as test-symbol.s 
$

reported via lkml

@nickdesaulniers nickdesaulniers added bug Indicates an unexpected problem or unintended behavior llvm:asmparser labels Feb 10, 2022
@llvmbot
Copy link
Collaborator

llvmbot commented Feb 10, 2022

@llvm/issue-subscribers-bug

@nickdesaulniers
Copy link
Member Author

nickdesaulniers commented Feb 11, 2022

slightly reduced case:

.text
.set start, .
  nop
.set end, .
.if end - start
.err
.endif

From what I can tell, it looks like when recursive evaluating the MCBinaryExpr::Sub in evaluateAsRelocatableImpl, the call to EvaluateSymbolicAdd returns true. MCExpr::evaluateAsAbsolute thinks the MCExpr is relocatable but not absolute.

I would think if . is in the same section, we might be able to compute the difference.

Even

.text

.set start, .
  nop
.set end, .

.ifeq end == start
.err
.endif

@nickdesaulniers
Copy link
Member Author

AttemptToFoldSymbolOffsetDifference in llvm/lib/MC/MCExpr.cpp looks like it might be helpful.

I feel like if the two symbols are in the same section (or at least the same fragment), we should be able to verify that their offsets are the same or different.

See also:

// On ELF and COFF A - B is absolute if A and B are in the same section.

// When layout is not finalized, our ability to resolve differences between
// symbols is limited to specific cases where the fragments between two
// symbols (including the fragments the symbols are defined in) are
// fixed-size fragments so the difference can be calculated. For example,
// this is important when the Subtarget is changed and a new MCDataFragment
// is created in the case of foo: instr; .arch_extension ext; instr .if . -
// foo.

@pskocik
Copy link

pskocik commented May 3, 2023

Hi. I seem to be experiencing a relevant issue in that while code such as your test-label.s works from an assembly file
(on both gcc and clang):

.text
start:
  nop
end:
.if (end - start) == 0
.err
.endif

a straightforward re-rendering of it in a C file fails on clang (not gcc) with "expected absolute expression":

__asm(
".text\n"
"start:\n"
"  nop\n"
"end:\n"
".if (end - start) == 0\n"
".err\n"
".endif\n"
);

@musamaanjum
Copy link

musamaanjum commented May 1, 2024

I've hit the same bug. Clang gives an error with the following extended asm:

<inline asm>:7:8: error: expected absolute expression
    7 |         .ifne . - test_page - 4096
      |               ^
<inline asm>:8:2: error: test page is not one page long
    8 |         .error "test page is not one page long"
      |         ^
asm (
	".pushsection \".text\", \"ax\"\n\t"
	".balign 4096\n\t"
	"test_page: .globl test_page\n\t"
	".fill 4094,1,0xcc\n\t"
	"test_syscall_insn:\n\t"
	"syscall\n\t"
	".ifne . - test_page - 4096\n\t"
	".error \"test page is not one page long\"\n\t"
	".endif\n\t"
	".popsection"
    );

But clang builds fine if the asm is moved to the assembly file, or by generating the asm by GCC and then building the asm to binary by clang.

@MaskRay
Copy link
Member

MaskRay commented May 4, 2024

The original report of expression folding in .if for MCObjectStreamer has been fixed https://reviews.llvm.org/D69411 and my followups.

The last two comments are about getUseAssemblerInfoForParsing() and should be discussed at #62520

@MaskRay MaskRay closed this as completed May 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Indicates an unexpected problem or unintended behavior llvm:asmparser
Projects
None yet
Development

No branches or pull requests

5 participants