| Summary: | binutils 2.28 Assertion failure in md_apply_fix at ../../gas/config/tc-aarch64.c:7766. | ||
|---|---|---|---|
| Product: | binutils | Reporter: | toregionsfair |
| Component: | gas | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | REOPENED --- | ||
| Severity: | minor | CC: | acoplan, joel.sherrill, nickc, tnfchris |
| Priority: | P2 | ||
| Version: | 2.36 | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | 2020-09-07 00:00:00 | |
| Attachments: |
gcc -v -save-temps output binutils 2.35
assembly Proposed patch |
||
|
Description
toregionsfair
2020-08-16 07:42:32 UTC
hmm binutils 2.28 is quite old.. does this happen with newer versions? Also would need a way to reproduce this. could you call gcc with `-save-temps` and attach the assembly file (if you can share the source). Created attachment 12806 [details]
gcc -v -save-temps output binutils 2.35
binutils 2.35 compile output
Created attachment 12807 [details]
assembly
Pre-alpha stage code generation
Since the error message is not gnu C or C++ related I don't mind to close this ticket, thanks. Status set to closed, see comment. Hmm an assert should never be hit though. It mean something didn't handle the error correctly. Reproduced on trunk. The attached assembly can be reduced to the following single instruction which causes an assertion failure:
$ echo "add x3,x3,:lo12:4" | aarch64-none-elf-as
{standard input}: Assembler messages:
{standard input}: Internal error in md_apply_fix at gas/config/tc-aarch64.c:8248.
Please report this bug.
*** Bug 27217 has been marked as a duplicate of this bug. *** (In reply to Alex Coplan from comment #8) > *** Bug 27217 has been marked as a duplicate of this bug. *** It may be the same assert but I don't think it is the same trigger. The C code in that ticket compiled successfully on every architecture: extern char bar[]; char * foo(void) { return bar; } __asm__ (".set bar, 0"); And there was output assembly showing the breakage. Any fix needs to be vetted against both test case code snippets. Created attachment 13354 [details] Proposed patch Hi Guys, I have applied a patch to fix PR 27217, but that does not handle the second test case in this PR. So I have created a second patch here. With this applied the test fails to assemble, like this: % echo "add x3,x3,:lo12:4" | aarch64-linux-gnu-as {standard input}: Assembler messages: {standard input}:1: Error: relocation extension cannot be used with a constant at operand 3 -- `add x3,x3,:lo12:4' I feel that this is the correct way to handle this particular case, but you may not agree. Opinions ? Cheers Nick I can't say whether you are right or wrong on rejecting that assembly language but it looks like this started as something generated by GCC like our case. If gcc still generates that assembly statement, then it has some place that needs fixing as well. (In reply to Joel Sherrill from comment #11) > I can't say whether you are right or wrong on rejecting that assembly > language but it looks like this started as something generated by GCC like > our case. If gcc still generates that assembly statement, then it has some > place that needs fixing as well. Agreed. I am a little bit skeptical that the test Alex provided in comment #7 actually came from compilation by a compiler, since the offending expression is ":lo12<constant>" rather than ":lo12<symbol>". I would expect a compiler to resolve ":lo12<constant>" on its own and not need the assembler to step in. But, if this is compiler generated code, then maybe I do need to find a way for the assembler to handle it properly. |