[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 --- Comment #22 from Richard Biener --- There is target specific sanitizing of symbol names - if the name is really the issue then it should be _much_ more prevalent since all IPA cloning uses dots as well. clone_function_name produces them and ASM_FORMAT_PRIVATE_NAME is the "sanitizer" that's supposed to mangle it to correct form. But as the name suggests the definition of a local private symbol isn't supposed to go away without all of its uses so the real issue must be elsewhere in optimization. (thus asking for IPA dumps, specifically the .000i.cgraph dump which should mention when the compiler thinks the .LTHUNK5.lto_priv.0 goes away)
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 --- Comment #21 from Xi Ruoyao --- (In reply to Richard Biener from comment #20) > Indeed already the name, .LTHUNK5.lto_priv.0, hints at that this should be a > local symbol. Not sure why we end up with a .reloc then. > > ld $25,%got_disp(.LTHUNK5.lto_priv.0)($28) > .LEHB26 = . > .reloc 1f,R_MIPS_JALR,.LTHUNK5.lto_priv.0 > 1: jalr$25 > > this seems to be in _ZN4Sass6Parser16parse_parametersEv > > Maybe it's possible to reduce the testcase by bisecting the object files > necessary to produce the bogus LTRANS assembly? From that one can start > reducing the source of the necessary object files. > > Another interesting bit would be to see the IPA dumps of the broken LTRANS > unit. If you add -fdump-ipa-all-details to the link command you should get > dump files alongside the ltrans temp files. I can confirm that the workaround in gas (released in binutils-2.36) "fixes" the problem. Some function aliases named ".LTHUNK%d" are created in C++ FE (cp/method.c, L232). With LTO those are cloned as ".LTHUNK%d.lto_priv.%d". Functions aliases should not be named ".xxx" IMO. Perhaps names like __gcc_lthunk.%d is better.
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #20 from Richard Biener --- Indeed already the name, .LTHUNK5.lto_priv.0, hints at that this should be a local symbol. Not sure why we end up with a .reloc then. ld $25,%got_disp(.LTHUNK5.lto_priv.0)($28) .LEHB26 = . .reloc 1f,R_MIPS_JALR,.LTHUNK5.lto_priv.0 1: jalr$25 this seems to be in _ZN4Sass6Parser16parse_parametersEv Maybe it's possible to reduce the testcase by bisecting the object files necessary to produce the bogus LTRANS assembly? From that one can start reducing the source of the necessary object files. Another interesting bit would be to see the IPA dumps of the broken LTRANS unit. If you add -fdump-ipa-all-details to the link command you should get dump files alongside the ltrans temp files.
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 --- Comment #19 from Xi Ruoyao --- gas has added a workaround. I'll test it tomorrow.
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 --- Comment #18 from Xi Ruoyao --- Oh no. Now I think it's GCC side. According to gas doc https://sourceware.org/binutils/docs/as/Symbol-Names.html#Symbol-Names .LTHUNK5.lto_priv.0 should be a local label. But in our LTO output, this label is defined in libsass.so.1.0.0.ltrans1.s and used in other ltrans files.
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 --- Comment #17 from Xi Ruoyao --- Reported as https://sourceware.org/bugzilla/show_bug.cgi?id=27228
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 --- Comment #16 from Xi Ruoyao --- (In reply to Richard Biener from comment #15) > So I see that > >242: 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.
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 Richard Biener changed: What|Removed |Added Status|WAITING |UNCONFIRMED Version|10.0|10.2.0 Target|mips64 |mips64el-unknown-linux-gnua ||bi64 Ever confirmed|1 |0 --- Comment #15 from Richard Biener --- So I see that 242: 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.
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #14 from Xi Ruoyao ---
(In reply to Richard Biener from comment #13)
> (In reply to Xi Ruoyao from comment #9)
> > (In reply to rguent...@suse.de from comment #8)
> >
> > > I guess it is because -mxgot is supposed to be handled by the assembler?
> > > I see
> > >
> > > %{mgp32} %{mgp64} %{march=*} %{mxgot:-xgot} \
> > >
> > > in ASM_SPEC. I guess this doesn't make it to COLLECT_AS_OPTIONS
> > > and eventually makes it dropped from COLLECT_GCC_OPTIONS as well.
> >
> > I don't think so.
> >
> > I can reproduce this issue compiling spidermonkey (js interpreter) from
> > firefox-78 ESR. I'm using "-pipe" so I can easily find the parameters
> > passed to "as", using "ps -aux". "-xgot" is passed correctly.
> >
> > > Can you attach the full output of compiling & linking with -v added?
>
> ^^^ (output aka output on the console)
Reproduced again, building libsass.
The output without -mxgot:
https://bf.mengyan1223.wang/assets/gcc-97787/libsass_so_lto_output.tar.xz
The output with -mxgot:
https://bf.mengyan1223.wang/assets/gcc-97787/libsass_so_lto_output_mxgot.tar.xz
Full console output with --verbose is included in the tarballs, named
console.log.
> I think the issue should be visible from a simple hello world compiled
> with LTO and -mxgot (aka not using -xgot in the approproate places in the
> end, not failing the link in the end).
Actually I don't think it's a xgot issue... With or without -mxgot I got
exactly same error message.
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #13 from Richard Biener ---
(In reply to Xi Ruoyao from comment #9)
> (In reply to rguent...@suse.de from comment #8)
>
> > I guess it is because -mxgot is supposed to be handled by the assembler?
> > I see
> >
> > %{mgp32} %{mgp64} %{march=*} %{mxgot:-xgot} \
> >
> > in ASM_SPEC. I guess this doesn't make it to COLLECT_AS_OPTIONS
> > and eventually makes it dropped from COLLECT_GCC_OPTIONS as well.
>
> I don't think so.
>
> I can reproduce this issue compiling spidermonkey (js interpreter) from
> firefox-78 ESR. I'm using "-pipe" so I can easily find the parameters
> passed to "as", using "ps -aux". "-xgot" is passed correctly.
>
> > Can you attach the full output of compiling & linking with -v added?
^^^ (output aka output on the console)
I think the issue should be visible from a simple hello world compiled
with LTO and -mxgot (aka not using -xgot in the approproate places in the
end, not failing the link in the end).
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 --- Comment #12 from Xi Ruoyao --- "readelf -s js.ltrans2.ltrans.o" gives a strange unnamed UND symbol: 1411: 0 SECTION LOCAL DEFAULT UND I'm not sure what's happening...
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 --- Comment #11 from Xi Ruoyao --- In my case the error message is: /usr/bin/ld: js.ltrans2.ltrans.o: .symtab local symbol at index 1411 (>= sh_info of 404) /usr/bin/ld: js.ltrans2.ltrans.o: error adding symbols: bad value I've uploaded the "guilty" files, js.ltrans2.* to my server, at https://bf.mengyan1223.wang/assets/gcc-97787/ so someone can analysis it.
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 --- Comment #10 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #9) > (In reply to rguent...@suse.de from comment #8) > > Can you try using -mxgot -Wa,-xgot or -mxgot -Xassembler -xgot at > > compile time? > > I'm trying, though my gut feeling is that it won't work. There is no luck. "-mxgot -Wa,-xgot" gives the same error.
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #9 from Xi Ruoyao ---
(In reply to rguent...@suse.de from comment #8)
> I guess it is because -mxgot is supposed to be handled by the assembler?
> I see
>
> %{mgp32} %{mgp64} %{march=*} %{mxgot:-xgot} \
>
> in ASM_SPEC. I guess this doesn't make it to COLLECT_AS_OPTIONS
> and eventually makes it dropped from COLLECT_GCC_OPTIONS as well.
I don't think so.
I can reproduce this issue compiling spidermonkey (js interpreter) from
firefox-78 ESR. I'm using "-pipe" so I can easily find the parameters passed
to "as", using "ps -aux". "-xgot" is passed correctly.
> Can you attach the full output of compiling & linking with -v added?
>
> Can you try using -mxgot -Wa,-xgot or -mxgot -Xassembler -xgot at
> compile time?
I'm trying, though my gut feeling is that it won't work.
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #8 from rguenther at suse dot de ---
On Fri, 13 Nov 2020, bunk at stusta dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
>
> --- Comment #7 from Adrian Bunk ---
> (In reply to Richard Biener from comment #6)
> > I see. Still GCC or GAS produces a bogus object file (the original linker
> > error). It might be the new problem is an entirely different one? It looks
> > more and more like a target problem to me.
>
> My guess would be that the situations where -mxgot is required on 64bit MIPS
> are not (no longer?) handled properly with LTO.
>
> Note that when compiling from precompiled sources the linker also exits with
> an
> error, the main difference in that case is that the correct "relocation
> truncated to fit" error message is not output in the LTO case.
>
> More worrisome is that adding -mxgot to compiler and linker flags did not fix
> it in the LTO case.
I guess it is because -mxgot is supposed to be handled by the assembler?
I see
%{mgp32} %{mgp64} %{march=*} %{mxgot:-xgot} \
in ASM_SPEC. I guess this doesn't make it to COLLECT_AS_OPTIONS
and eventually makes it dropped from COLLECT_GCC_OPTIONS as well.
Can you attach the full output of compiling & linking with -v added?
Can you try using -mxgot -Wa,-xgot or -mxgot -Xassembler -xgot at
compile time?
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 --- Comment #7 from Adrian Bunk --- (In reply to Richard Biener from comment #6) > I see. Still GCC or GAS produces a bogus object file (the original linker > error). It might be the new problem is an entirely different one? It looks > more and more like a target problem to me. My guess would be that the situations where -mxgot is required on 64bit MIPS are not (no longer?) handled properly with LTO. Note that when compiling from precompiled sources the linker also exits with an error, the main difference in that case is that the correct "relocation truncated to fit" error message is not output in the LTO case. More worrisome is that adding -mxgot to compiler and linker flags did not fix it in the LTO case.
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 Richard Biener changed: What|Removed |Added Component|lto |target CC||mfortune at gmail dot com --- Comment #6 from Richard Biener --- I see. Still GCC or GAS produces a bogus object file (the original linker error). It might be the new problem is an entirely different one? It looks more and more like a target problem to me. CCing the mips maintainer.
