Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/debug/pr41893-1.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -gdwarf-2 -g1 -flto -fwhole-program -O /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/debug/pr41893-2.c -lm -o pr41893-1.exe (timeout = 300) spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/debug/pr41893-1.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -gdwarf-2 -g1 -flto -fwhole-program -O /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/debug/pr41893-2.c -lm -o pr41893-1.exe ld: Unsatisfied hidden symbol "". Symbol was referenced from file /var/tmp//cc3R5QJu.debug.temp.o ld: Unsatisfied hidden symbol "". Symbol was referenced from file /var/tmp//cc3R5QJu.debug.temp.o ld: Unsatisfied hidden symbol "". Symbol was referenced from file /var/tmp//cc3R5QJu.debug.temp.o ld: Unsatisfied hidden symbol "". Symbol was referenced from file /var/tmp//ccCZBOzC.debug.temp.o 4 errors. collect2: fatal error: ld returned 1 exit status compilation terminated. compiler exited with status 1
Is this a new failure, thus can it be bisected somehow?
On 2019-08-19 2:51 a.m., rguenth at gcc dot gnu.org wrote: > Is this a new failure, thus can it be bisected somehow? New. I can say at this point that r273635 was okay. There was a testsuite problem with r274010 but it appears that it might have been okay as well.
On 2019-08-19 2:51 a.m., rguenth at gcc dot gnu.org wrote: > Is this a new failure, thus can it be bisected somehow? The failure was introduced in r273662: https://gcc.gnu.org/ml/gcc-cvs/2019-07/msg00827.html
See PR lto/83452: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83452
Previously, we had in pr41893-1.o.debug.temp.o: w gnu_lto_v1 w gnu_lto_v1 w gnu_lto_v1 w gnu_lto_v1 0000000000000000 W pr41893_1.c.ebbf0839 Now we have: w w w 0000000000000000 W pr41893_1.c.ebbf0839 The gnu_lto_v1 symbol was resolved by libgcc.a hack.
Then mine.
@John: Which GCC version are you testing? Do you have following trunk commit: Fix off-by-one in simple-object-elf.c (PR lto/91228). 2019-07-24 Martin Liska <mliska@suse.cz> PR lto/91228 * simple-object-elf.c (simple_object_elf_copy_lto_debug_sections): Find first '\0' starting from gnu_lto + 1. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@273757 138bc75d-0d04-0410-961f-82ee72b054a4 ?
On 2019-08-23 7:20 a.m., marxin at gcc dot gnu.org wrote: > Which GCC version are you testing? Do you have following trunk commit: I am testing trunk. The error in Comment #1 was for r274539. > > Fix off-by-one in simple-object-elf.c (PR lto/91228). > > 2019-07-24 Martin Liska <mliska@suse.cz> > > PR lto/91228 > * simple-object-elf.c (simple_object_elf_copy_lto_debug_sections): > Find first '\0' starting from gnu_lto + 1. > > > git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@273757 > 138bc75d-0d04-0410-961f-82ee72b054a4 The symbols shown by nm in Comment #5 compared r273661 and r273662. Thus, the symbols for r273662 are affected by the off-by-one bug. In order to do regression search, I also had to apply this patch: Index: lto-wrapper.c =================================================================== --- lto-wrapper.c (revision 274037) +++ lto-wrapper.c (working copy) @@ -1112,7 +1112,7 @@ /* Number of CPUs that can be used for parallel LTRANS phase. */ -static unsigned long nthreads_var = 0; +static unsigned long nthreads_var = 1; #ifdef HAVE_PTHREAD_AFFINITY_NP unsigned long cpuset_size; This is because make objects to "-j0". 64-Bit HP ld issues errors or warnings about unstats depending on +[no]allowunsats option. It doesn't help to allow unstats as the dynamic linker will object to unstats in an executable when it is run. So, the symbols that used to turn into gnu_lto_v1 need to turn into a common or defined weak symbol on this target.
Yeah, we went though this back in time when I struggled to find a solution working in all environments we support (HP ld, Solaris ld, AIX ld).
(In reply to Richard Biener from comment #9) > Yeah, we went though this back in time when I struggled to find a solution > working in all environments we support (HP ld, Solaris ld, AIX ld). Hm, does it mean I'll have to revert all the removal of gnu_lto_v1?
On Fri, 23 Aug 2019, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91478 > > --- Comment #10 from Martin Liška <marxin at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #9) > > Yeah, we went though this back in time when I struggled to find a solution > > working in all environments we support (HP ld, Solaris ld, AIX ld). > > Hm, does it mean I'll have to revert all the removal of gnu_lto_v1? Well, at least I doubt we can add a weak def of "". As I said repeatedly the other option is to really remove symbols but that entails rewriting all relocation sections (ick). Previously we've had libgcc "provide" the __gnu_lto_v1 symbol (that was a hack, but it worked...). I guess we might want to at least _try_ doing the right thing and remove the symbols for real... I guess rematerializing gnu_lto_v1 just for the sake of removed symbols would be odd. I wonder what happens when we instead of aliasing the removed to UNDEF gnu_lto_v1 (or "" as now) use a random symbol that prevails... (we should have at least one for the debuginfo entry). Then we'd have 19: 0000000000000000 0 NOTYPE WEAK HIDDEN 4 t.c.61d57031 20: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND t.c.61d57031 for example. Of course we then need to figure which linkers are happy with that and which not... And we need to do two passes over the symtab as we need to find a prevailing symbol to use.
Created attachment 46745 [details] Patch candidate Ok, now I'm more understanding the code in simple_object_elf_copy_lto_debug_sections and I implemented the suggested approach. @John: Can you please test it?
On 2019-08-23 10:09 a.m., marxin at gcc dot gnu.org wrote: > Ok, now I'm more understanding the code in > simple_object_elf_copy_lto_debug_sections and I implemented the suggested > approach. I still see the error: COMPILER_PATH=/test/gnu/gcc/objdir/gcc/:/test/gnu/gcc/objdir/gcc/:/usr/ccs/bin/: /usr/ccs/bin LIBRARY_PATH=/test/gnu/gcc/objdir/gcc/:/test/gnu/gcc/objdir/gcc/:/usr/ccs/lib/pa 20_64/:/opt/langtools/lib/pa20_64/:/lib/pa20_64/:/usr/lib/pa20_64/:/usr/ccs/lib/ pa20_64/:/opt/langtools/lib/pa20_64/:/lib/pa20_64/:/usr/lib/pa20_64/ COLLECT_GCC_OPTIONS='-fdiagnostics-color=never' '-c' '-fno-openmp' '-fno-openacc ' '-fPIC' '-O1' '-B' '/test/gnu/gcc/objdir/gcc/' '-fno-diagnostics-show-caret' ' -fno-diagnostics-show-line-numbers' '-gdwarf-2' '-g1' '-fwhole-program' '-O' '-v ' '-save-temps' '-dumpdir' './' '-dumpbase' 'pr41893-1.exe.ltrans0' '-fltrans' ' -o' 'pr41893-1.exe.ltrans0.ltrans.o' [Leaving LTRANS pr41893-1.exe.ltrans0.o] ld: Unsatisfied hidden symbol "". Symbol was referenced from file pr41893-1.o.de bug.temp.o ld: Unsatisfied hidden symbol "". Symbol was referenced from file pr41893-1.o.de bug.temp.o ld: Unsatisfied hidden symbol "". Symbol was referenced from file pr41893-1.o.de bug.temp.o ld: Unsatisfied hidden symbol "". Symbol was referenced from file pr41893-2.o.de bug.temp.o 4 errors. collect2: fatal error: ld returned 1 exit status compilation terminated. readelf shows: Symbol table '.symtab' contains 31 entries: Num: Value Size Type Bind Vis Ndx Name 29: 0000000000000000 0 NOTYPE WEAK HIDDEN 1 pr41893_2.c.f7e743e4 30: 0000000000000000 4 NOTYPE WEAK HIDDEN UND
On 2019-08-23 3:40 p.m., dave.anglin at bell dot net wrote: > readelf shows: > > Symbol table '.symtab' contains 31 entries: > Num: Value Size Type Bind Vis Ndx Name > > 29: 0000000000000000 0 NOTYPE WEAK HIDDEN 1 pr41893_2.c.f7e743e4 > 30: 0000000000000000 4 NOTYPE WEAK HIDDEN UND For the other file: 30: 0000000000000000 0 NOTYPE WEAK HIDDEN 1 pr41893_1.c.ebbf0839 31: 0000000000000000 4 NOTYPE WEAK HIDDEN UND 32: 0000000000000000 8 NOTYPE WEAK HIDDEN UND 33: 0000000000000000 4 NOTYPE WEAK HIDDEN UND
Created attachment 46747 [details] ld symbol resolution
Created attachment 46751 [details] Debugging patch Can you please apply the patch and run something like: $ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/debug/pr41893-1.c -flto -g -O2 -c $ DEBUGME=1 gcc pr41893-1.o --save-temps $ readelf -s -W pr41893-1.o.debug.temp.o I would appreciate output of all 3 commands. Thanks.
Created attachment 46754 [details] .o file from step 1
Created attachment 46755 [details] Output from step 2
Created attachment 46756 [details] Output from step 3 (readelf)
Created attachment 46757 [details] Debugging patch Thanks. I probably know what's wrong. Please try v2 of the debugging patch?
Created attachment 46758 [details] Clean up patch that should work This is a rebased patch candidate (without debugging output). The patch should work for you. Can you please test it as well?
On 2019-08-26 10:55 a.m., marxin at gcc dot gnu.org wrote: > This is a rebased patch candidate (without debugging output). The patch should > work for you. Can you please test it as well? > Okay. It will take a bit as I had to restart build with last debugging patch.
Created attachment 46759 [details] Output from step2 (v2)
Created attachment 46760 [details] Output from step 3 (v2)
On 2019-08-26 10:55 a.m., marxin at gcc dot gnu.org wrote: > This is a rebased patch candidate (without debugging output). The patch should > work for you. Can you please test it as well? Looking good! It fixes the testcase. Full build and check started.
> Looking good! It fixes the testcase. Full build and check started. Great, then I'm going to send the patch to mailing list. Thanks a lot for the testing.
Patch has been sent: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01813.html
Author: marxin Date: Tue Aug 27 13:36:15 2019 New Revision: 274955 URL: https://gcc.gnu.org/viewcvs?rev=274955&root=gcc&view=rev Log: Share a prevailing name for remove debug info symbols w/ LTO. 2019-08-27 Martin Liska <mliska@suse.cz> PR lto/91478 * simple-object-elf.c (simple_object_elf_copy_lto_debug_sections): First find a WEAK HIDDEN symbol in symbol table that will be preserved. Later, use the symbol name for all removed symbols. Modified: trunk/libiberty/ChangeLog trunk/libiberty/simple-object-elf.c
Should be fixed now.