[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 Tom de Vries changed: What|Removed |Added CC||vries at gcc dot gnu.org --- Comment #14 from Tom de Vries --- (In reply to Jakub Jelinek from comment #13) > The GDB missing feature/bug worked around for GCC 8, hopefully GDB will be > fixed soon and we can remove the workaround at some point. Filed a GDB PR to track the worked-around issue in GDB: - https://sourceware.org/bugzilla/show_bug.cgi?id=26095 Filed a GCC PR to tested whether the workaround is still required: - PR95601 - "Remove workaround for GDB PR in pass_partition_blocks::gate"
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Jakub Jelinek --- The GDB missing feature/bug worked around for GCC 8, hopefully GDB will be fixed soon and we can remove the workaround at some point.
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 --- Comment #12 from Jakub Jelinek --- Author: jakub Date: Fri Jan 12 18:20:49 2018 New Revision: 256592 URL: https://gcc.gnu.org/viewcvs?rev=256592=gcc=rev Log: PR debug/81155 * bb-reorder.c (pass_partition_blocks::gate): In lto don't partition main to workaround a bug in GDB. Modified: trunk/gcc/ChangeLog trunk/gcc/bb-reorder.c
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 --- Comment #11 from Jakub Jelinek --- Well, we certainly don't want to disable partitioning for all functions if in LTO, that would be extremely costly. Most of real-world programs don't do all the work in main, so disabling that may be acceptable. But as I said, when doing break main or l main etc. it just seems to work fine, it is just the initial current file that is broken if main has DW_AT_ranges and a partial DIE. Note GCC 8 turns -freorder-blocks-and-partition by default, something that has been done in the past only for PGO builds (-fprofile-use), so there will be significantly more functions with DW_AT_ranges now.
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 --- Comment #10 from Jan Kratochvil --- It should affect all functions, not just main. But then GDB already needlessly expands so many CUs that usually when some function is needed its CU is already expanded. So maybe it is seen just accidentally on one trivial testcase.
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 --- Comment #9 from Jakub Jelinek --- Created attachment 43114 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43114=edit gcc8-pr81155.patch Untested workaround till GDB is fixed, disable partitioning of main in lto.
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 --- Comment #8 from Jan Kratochvil --- (In reply to Jakub Jelinek from comment #7) > Thanks. Is that something that can be fixed in GDB easily? Expecting a significant performance hit on initial scan of a file when .gdb_index/.debug_names is not present there. But personally I do not think that matters as such scanning without any index was always very slow, that is what the index is there for. I am leaving the fix and/or assignment of the fix up to Pedro.
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 --- Comment #7 from Jakub Jelinek --- Thanks. Is that something that can be fixed in GDB easily? I mean, for -freorder-blocks-and-partition optimized main we can't pretend it is a single range when it is not.
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 --- Comment #6 from Jan Kratochvil --- (In reply to Jakub Jelinek from comment #5) > where gdb sees the difference and why doesn't it make the file > containing main the default? pr43051-1.exe.good <1><117>: Abbrev Number: 3 (DW_TAG_subprogram) <118> DW_AT_abstract_origin: <0x69> <11c> DW_AT_low_pc : 0x400410 <124> DW_AT_high_pc : 0x3d ... pr43051-1.exe.bad <1><117>: Abbrev Number: 3 (DW_TAG_subprogram) <118> DW_AT_abstract_origin: <0x69> <11c> DW_AT_ranges : 0x0 ... GDB read_partial_die() does support DW_AT_low_pc+DW_AT_high_pc but not DW_AT_ranges. Therefore for pr43051-1.exe.bad GDB considers it only as a declaration of main() and not its definition, not worth expanding its CU.
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155
Jakub Jelinek changed:
What|Removed |Added
CC||jan.kratochvil at redhat dot
com,
||palves at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
So, I guess we need help on how does gdb determine the initial file when
loading a program (i.e. when you run gdb ./program , when you get prompt, what
file is l showing or b putting breakpoint in).
With the new LTO debug info, we have
.file ""
with both -f{,no-}reorder-blocks-and-partition.
The CU that imports the unit with main has:
.long .LASF1 # DW_AT_name: ""
.long .LASF2 # DW_AT_comp_dir: "/usr/src/gcc/obj/gcc"
too. Pedro/Jan, could you try this (I can provide binaries off-line) and say
where gdb sees the difference and why doesn't it make the file containing main
the default?
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
As
make check-gcc
RUNTESTFLAGS='--target_board=unix\{-fno-reorder-blocks-and-partition,-freorder-blocks-and-partition\}
guality.exp=pr43051-1.c'
shows, it is a -freorder-blocks-and-partition related, but it actually isn't
about missing debug info for those vars, it is all there.
gdb ./pr43051-1.exe
(gdb) b pr43051-1.c:34
Breakpoint 2 at 0x4005ff: file
/usr/src/gcc/gcc/testsuite/gcc.dg/guality/pr43051-1.c, line 34.
(gdb) r
Starting program: /usr/src/gcc/obj/gcc/pr43051-1.exe
Breakpoint 2, bar (c=0x601060 , v=1, e=0x601070 ) at
/usr/src/gcc/gcc/testsuite/gcc.dg/guality/pr43051-1.c:34
34foo ("c", (__UINTPTR_TYPE__) c, 0); /* { dg-final {
gdb-test 34 "c" "\\[0\]" } } */
(gdb) p c
$1 = (struct S *) 0x601060
(gdb) n
35foo ("v", v, 1); /* { dg-final {
gdb-test 35 "v" "1" } } */
(gdb) p v
$2 = 1
(gdb) n
36foo ("e", (__UINTPTR_TYPE__) e, 2); /* { dg-final {
gdb-test 36 "e" "\\[1\]" } } */
(gdb) p e
$3 = (struct S *) 0x601070
(gdb) b 39
Breakpoint 3 at 0x4005c0: file
/usr/src/gcc/gcc/testsuite/gcc.dg/guality/pr43051-1.c, line 39.
(gdb) c
Continuing.
Breakpoint 3, bar (c=0x601060 , v=1, e=0x601070 ) at
/usr/src/gcc/gcc/testsuite/gcc.dg/guality/pr43051-1.c:39
39foo ("c", (__UINTPTR_TYPE__) c, 3); /* { dg-final {
gdb-test 39 "c" "\\[0\]" } } */
(gdb) p c
$4 = (struct S *) 0x601060
(gdb) n
40foo ("v", v, 4); /* { dg-final {
gdb-test 40 "v" "1" } } */
(gdb) p v
$5 = 1
(gdb) n
41foo ("e", (__UINTPTR_TYPE__) e, 5); /* { dg-final {
gdb-test 41 "e" "\\[1\]" } } */
(gdb) p e
$6 = (struct S *) 0x601070
The reason it fails is different, in the logs there is:
spawn gdb -nx -nw -quiet -batch -x pr43051-1.gdb ./pr43051-1.exe
No line 34 in the current file.
Make breakpoint pending on future shared library load? (y or [n]) [answered N;
input not from terminal]
and indeed that is what one can see:
gdba ./pr43051-1.exe
(gdb) l
1 : No such file or directory.
(gdb) b 34
No line 34 in the current file.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (34) pending.
So, either gdb 8.0.1-33.fc27 is too old to handle the LTO debug info, or there
is something wrong in it.
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-12-08 CC||aldyh at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Aldy Hernandez --- Confirmed on trunk.
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0 Summary|Debug make check|[8 Regression] Debug make |regressions in GCC 8.0 |check regressions in GCC ||8.0
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 H.J. Lu changed: What|Removed |Added CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot com --- Comment #4 from H.J. Lu --- (In reply to Richard Biener from comment #3) > > Adding -fno-reorder-blocks-and-partition to the test fixes things but I > wonder > what causes the debug info to degrade (or gdb to barf). I think HJs pending > patch in this area might fix things? No, my patch doesn't fix it.
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-14 CC||hjl at gcc dot gnu.org, ||hubicka at gcc dot gnu.org Target Milestone|--- |8.0 Summary|Debug make check|[8 Regression] Debug make |regressions in GCC 8.0 |check regressions in GCC ||8.0 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Ok, confirmed. Before Honzas change flag_split_stack was -1 (aka default which is supposed to mean 'off' if the target doesn't override that). That caused reorder-and-partition to be disabled if not explicitely enabled. The new guality FAILs happen for all option flags, not just LTO (this was what confused me). FAIL: gcc.dg/guality/pr45882.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 16 d == 112 FAIL: gcc.dg/guality/pr45882.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 16 e == 142 is present even before the change. Adding -fno-reorder-blocks-and-partition to the test fixes things but I wonder what causes the debug info to degrade (or gdb to barf). I think HJs pending patch in this area might fix things?
