Bug 26395 - binutils 2.28 Assertion failure in md_apply_fix at ../../gas/config/tc-aarch64.c:7766.
Summary: binutils 2.28 Assertion failure in md_apply_fix at ../../gas/config/tc-aarch6...
Status: REOPENED
Alias: None
Product: binutils
Classification: Unclassified
Component: gas (show other bugs)
Version: 2.36
: P2 minor
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-16 07:42 UTC by toregionsfair
Modified: 2021-04-07 09:09 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed: 2020-09-07 00:00:00


Attachments
gcc -v -save-temps output binutils 2.35 (829 bytes, text/plain)
2020-08-27 16:59 UTC, toregionsfair
Details
assembly (694 bytes, text/plain)
2020-08-27 17:09 UTC, toregionsfair
Details
Proposed patch (384 bytes, patch)
2021-04-06 15:50 UTC, Nick Clifton
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description toregionsfair 2020-08-16 07:42:32 UTC
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/6/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18+deb9u1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-arm64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-arm64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-arm64 --with-arch-directory=aarch64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-multiarch --enable-fix-cortex-a53-843419 --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) 
COLLECT_GCC_OPTIONS='-v' '-o' 'yout' '-mlittle-endian' '-mabi=lp64'
 as -v -EL -mabi=lp64 -o /tmp/ccfo17Id.o y_assign_06.s
GNU assembler version 2.28 (aarch64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.28
y_assign_06.s: Assembler messages:
y_assign_06.s: Internal error!
Assertion failure in md_apply_fix at ../../gas/config/tc-aarch64.c:7766.
Please report this bug.
Comment 1 Tamar Christina 2020-08-17 11:16:23 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).
Comment 2 toregionsfair 2020-08-27 16:59:22 UTC
Created attachment 12806 [details]
gcc -v -save-temps output binutils 2.35

binutils 2.35 compile output
Comment 3 toregionsfair 2020-08-27 17:09:09 UTC
Created attachment 12807 [details]
assembly

Pre-alpha stage code generation
Comment 4 toregionsfair 2020-09-05 16:58:26 UTC
Since the error message is not gnu C or C++ related I don't mind to close this ticket, thanks.
Comment 5 toregionsfair 2020-09-05 17:03:35 UTC
Status set to closed, see comment.
Comment 6 Tamar Christina 2020-09-07 08:44:32 UTC
Hmm an assert should never be hit though. It mean something didn't handle the error correctly.
Comment 7 Alex Coplan 2020-09-07 08:59:21 UTC
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.
Comment 8 Alex Coplan 2021-03-12 14:47:15 UTC
*** Bug 27217 has been marked as a duplicate of this bug. ***
Comment 9 Joel Sherrill 2021-03-12 15:14:44 UTC
(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.
Comment 10 Nick Clifton 2021-04-06 15:50:56 UTC
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
Comment 11 Joel Sherrill 2021-04-06 16:45:36 UTC
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.
Comment 12 Nick Clifton 2021-04-07 09:09:06 UTC
(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.