https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #16 from Xi Ruoyao <xry111 at mengyan1223 dot wang> ---
(In reply to Richard Biener from comment #15)
> So I see that
>
> 242: 0000000000000000 0 SECTION LOCAL DEFAULT UND
>
> and that's indeed broken (UND SECTION?) but ld complains that the SECTION
> type is after the last section entry. So next up would be to look at the
> assembly file the compiler generates for libsass.so.1.0.0.ltrans16.ltrans.o.
>
> The console output shows how it's generated:
>
> as -v -EL -mips64r2 -mips64r2 -mmsa -mloongson-ext -mloongson-ext
> -mloongson-ext2 -mloongson-ext2 -O2 -mabi=64 -mabi=64 -march=gs464e
> -march=gs464e -march=gs464e -mtune=gs464e -mtune=gs464e -mtune=gs464e -KPIC
> -o libsass.so.1.0.0.ltrans16.ltrans.o libsass.so.1.0.0.ltrans16.s
>
> and the "last" section I see in there is
>
> .section .note.GNU-stack,"",@progbits
>
> and I can confirm that GNU as (2.35.1) produces an object with the strange
> section (using a cross binutils). I think that no valid assembly file
> should produce that so may I suggest to file a bug at sourceware for an
> assembler issue? (just use the libsass.so.1.0.0.ltrans16.s file as testcase)
>
> Maybe there's more mips people around than here.
I managed to make a smallest testcase (by removing lines in ltrans16.s) to
generate such a buggy section:
.text
foo:
.reloc 1f,R_MIPS_JALR,.LTHUNK5.lto_priv.0
1: nop
I'm not a toolchain expert. If you believe it looks like a gas bug, let's
report it to gas.
