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

Macro expansion fails with "expected absolute expression" #41170

Closed
isanbard opened this issue May 10, 2019 · 10 comments
Closed

Macro expansion fails with "expected absolute expression" #41170

isanbard opened this issue May 10, 2019 · 10 comments
Assignees
Labels
bugzilla Issues migrated from bugzilla mc Machine (object) code

Comments

@isanbard
Copy link
Contributor

Bugzilla Link 41825
Resolution FIXED
Resolved on Nov 18, 2019 09:29
Version trunk
OS All
CC @jcai19,@jyknight,@kbeyls,@nickdesaulniers,@ostannard,@smithp35,@stephenhines

Extended Description

This is seen when compiling Linux with the integrated assembler. It was first seen in AArch64, but isn't specific to that platform.

$ cat bad.s
.macro jump_slot jumptable, index, label
.if (. - \jumptable) != 4 * (\index)
.error "Jump slot index mismatch"
.endif
b \label
.endm

.text
jumptable:
jump_slot jumptable, 0, realtime

$ clang -cc1as -triple aarch64-grtev4-linux-gnu -target-cpu generic -target-feature +neon -mrelocation-model static -o /dev/null bad.s
:1:5: error: expected absolute expression
.if (. - jumptable) != 4 * (0)
^
bad.s:10:3: note: while in macro instantiation
jump_slot jumptable, 0, realtime
^
:2:1: error: Jump slot index mismatch
.error "Jump slot index mismatch"
^
bad.s:10:3: note: while in macro instantiation
jump_slot jumptable, 0, realtime
^

@isanbard
Copy link
Contributor Author

assigned to @jyknight

@smithp35
Copy link
Collaborator

This will reproduce without a macro and on any target
.text
jumptable:
.if (. - jumptable) != 0
.error "1"
.endif
nop

The .if directive is using parseAbsoluteExpression(). What needs to be worked out is whether (. - jumptable) != 0 is not considered absolute. Given that jumptable is before the directive I think that this can evaluate to an absolute constant.

@isanbard
Copy link
Contributor Author

Is there an easy way to convince MC that this is an absolute expression?

@smithp35
Copy link
Collaborator

Not that I know of sorry. The only thing I could think to try was:
.globl offset
.equ offset, (. - jumptable)
.if (offset != 0)
sadly MC still thinks offset is not absolute.

Looking at the MCExpr code I think that this is because the code for .if uses evaluateAsAbsolute(Expr);

There are alternative forms of evaluate that include MCAsmLayout which I think MCExpr needs to know that . - jumptable is a constant.

@isanbard
Copy link
Contributor Author

It's just that the parser doesn't have access to the MCAsmLayout object and I'm not sure how to pass it to the parser.

@smithp35
Copy link
Collaborator

I see what you mean. Now that I think about it I don't think that there is going to be an easy way of solving this in MC. The largest problem with .if is that it can affect the layout itself, for example:

label:
relaxable-relative-branch-to label2:
.if (condition)
one instruction
.else
many instructions
.endif
label2:

if the condition passes then a small branch instruction can be used, if it fails then a larger relaxed one might be needed, which might then change the value of condition.

I'm thinking that the closest MC is likely to get to being able to evaluate

    .text

jumptable:
.if (. - jumptable)
is if the label is in the same non relaxable Fragment so that the .if can be resolved without affecting the . - jumptable.

I don't think that this can be accomplished by the existing evaluate expression code though.

@jcai19
Copy link
Member

jcai19 commented Nov 9, 2019

Different from a similar issue llvm/llvm-bugzilla-archive#43759 , which is caused by .if comparing two symbols in consecutive fragments, this issue is due to MC parses a .if statement before a real MCDataFragment created. Symbols are created and placed in a MCDummyFragment, and re-associated with a real fragment when created. If a .if statement is the first to parse within a code fragment, then MC will fail to evaluate the difference of their offsets since the symbols are still in the dummy fragment. I tried to solve this problem when symbols are emitted, which however caused regression and the reason was not easy to identify. So eventually I had to fix the issue when the comparison happens, in a similar way to how I fix llvm/llvm-bugzilla-archive#43759 at https://reviews.llvm.org/D69411. Feel free to suggest a better fix. Thanks.

@nickdesaulniers
Copy link
Member

jyknight has also authored https://reviews.llvm.org/D70062 referencing this issue.

@jcai19
Copy link
Member

jcai19 commented Nov 11, 2019

jyknight has also authored https://reviews.llvm.org/D70062 referencing this
issue.

Yes this is a better solution, I have removed the redundant code from my patch.

@nickdesaulniers
Copy link
Member

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla mc Machine (object) code
Projects
None yet
Development

No branches or pull requests

4 participants