[Bug debug/95360] inconsistent behaviors at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |MOVED --- Comment #8 from Andrew Pinski --- This is a gdb issue so closing as moved.
[Bug debug/95360] inconsistent behaviors at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360 --- Comment #7 from Tom de Vries --- (In reply to Tom de Vries from comment #4) > So, it seems gdb ignores the "recommended breakpoint location" at 0x4004cb, > because there's an earlier one on the same line at 0x4004bc. > > The gdb approach is reasonable, but it could do better. > I found how to disable this behaviour in gdb, and then we do step from line 5 to line 6. Filed gdb PR https://sourceware.org/bugzilla/show_bug.cgi?id=26054 .
[Bug debug/95360] inconsistent behaviors at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360 --- Comment #6 from Yibiao Yang --- (In reply to Jonathan Wakely from comment #2) > (In reply to Yibiao Yang from comment #0) > > As showed, Line 6 is hit first and then hit Line 7 with stepi. > > However, when using step, gdb is first hit Line 7 and then hit Line 6. > > This is an inconsistent behaviors between stepi and step > > Why is that a bug? Why is it a GCC bug? To be honest, I am not sure whether this is a gcc bug or a gdb bug. I am very sorry for that. I report it here as I doubt that the line table is generated incorrectly by compilers.
[Bug debug/95360] inconsistent behaviors at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360 --- Comment #5 from Yibiao Yang --- (In reply to Tom de Vries from comment #3) > (In reply to Yibiao Yang from comment #0) > > Breakpoint 1, main () at small.c:5 > > 5 for (; d<1; d++) > > (gdb) stepi > > 0x00401154 5 for (; d<1; d++) > > (gdb) stepi > > 0x0040115a 5 for (; d<1; d++) > > (gdb) stepi > > 0x0040115c 5 for (; d<1; d++) > > (gdb) stepi > > 0x0040113b 6 for (; b<1; b++) > > (gdb) stepi > > 0x00401141 6 for (; b<1; b++) > > (gdb) stepi > > 0x00401143 6 for (; b<1; b++) > > (gdb) stepi > > 7 c[b][d+1] = 0; > > (gdb) > > > > > > /* > > As showed, Line 6 is hit first and then hit Line 7 with stepi. > > However, when using step, gdb is first hit Line 7 and then hit Line 6. > > This is an inconsistent behaviors between stepi and step > > */ > > Gdb is behaving consistently in the following sense: > - when gdb is at a "recommended breakpoint location" it shows the source line > only with line number prefix. > - otherwise, it shows the source line with both address and line number > prefix. > > So, what the stepi sequence shows it that the next "recommended breakpoint > location" after line 5 is line 7, which is consistent with a step from line > 5 to line 7. I agree that at some time it will step to line 7 after executing line 6 and at other times it will step to line 6 after executing line7 as they both at the same iteration. However, my concern is that for the "first iteration or first time" line 6 should be hit ahead of line 7 no matter on whether we using step or using stepi. That's to say, the first hit of Line 6 or Line 7 should be consistent between step and stepi.
[Bug debug/95360] inconsistent behaviors at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360 --- Comment #4 from Tom de Vries --- I compiled the test-case: ... $ gcc-10 -O0 -g small.c ... And did the stepi scenario: ... $ gdb a.out -batch -ex start $(for n in $(seq 1 7); do echo -ex si; done) Temporary breakpoint 1 at 0x400496: file small.c, line 5. Temporary breakpoint 1, main () at small.c:5 5 for (; d<1; d++) 0x004004e4 5 for (; d<1; d++) 0x004004ea 5 for (; d<1; d++) 0x004004ec 5 for (; d<1; d++) 0x004004cb 6 for (; b<1; b++) 0x004004d1 6 for (; b<1; b++) 0x004004d3 6 for (; b<1; b++) 7 c[b][d+1] = 0; ... The line table gdb uses is: ... $ gdb a.out -batch -ex start -ex "maint info line-table" Temporary breakpoint 1 at 0x400496: file small.c, line 5. Temporary breakpoint 1, main () at small.c:5 5 for (; d<1; d++) objfile: a.out ((struct objfile *) 0x2f2f520) compunit_symtab: ((struct compunit_symtab *) 0x2f618e0) symtab: small.c ((struct symtab *) 0x2f61960) linetable: ((struct linetable *) 0x2fa3ae0): INDEX LINE ADDRESSIS-STMT 0 4 0x00400492 Y 1 5 0x00400496 Y 2 7 0x00400498 Y 3 6 0x004004bc Y 4 5 0x004004d5 Y 5 9 0x004004ee Y 6 10 0x004004f3 Y 7 END0x004004f5 Y ... And indeed, the insn at 0x004004cb is not a "recommended breakpoint location" in this table. However, if we look in the line number program using readelf -wl we see an entry with that address: ... [0x0145] Special opcode 215: advance Address by 15 to 0x4004cb and Line by 0 to 6 ... The whole line number program looks like this: ... Line Number Statements: [0x0111] Set column to 12 [0x0113] Extended opcode 2: set Address to 0x400492 [0x011e] Special opcode 8: advance Address by 0 to 0x400492 and Line by 3 to 4 [0x011f] Set column to 3 [0x0121] Special opcode 62: advance Address by 4 to 0x400496 and Line by 1 to 5 [0x0122] Set column to 11 [0x0124] Extended opcode 4: set Discriminator to 2 [0x0128] Special opcode 35: advance Address by 2 to 0x400498 and Line by 2 to 7 [0x0129] Set column to 13 [0x012b] Extended opcode 4: set Discriminator to 2 [0x012f] Special opcode 89: advance Address by 6 to 0x40049e and Line by 0 to 7 [0x0130] Set column to 17 [0x0132] Extended opcode 4: set Discriminator to 2 [0x0136] Special opcode 131: advance Address by 9 to 0x4004a7 and Line by 0 to 7 [0x0137] Set column to 18 [0x0139] Extended opcode 4: set Discriminator to 2 [0x013d] Advance PC by constant 17 to 0x4004b8 [0x013e] Special opcode 60: advance Address by 4 to 0x4004bc and Line by -1 to 6 [0x013f] Set column to 13 [0x0141] Extended opcode 4: set Discriminator to 1 [0x0145] Special opcode 215: advance Address by 15 to 0x4004cb and Line by 0 to 6 [0x0146] Set column to 5 [0x0148] Extended opcode 4: set Discriminator to 1 [0x014c] Special opcode 89: advance Address by 6 to 0x4004d1 and Line by 0 to 6 [0x014d] Set column to 16 [0x014f] Special opcode 60: advance Address by 4 to 0x4004d5 and Line by -1 to 5 [0x0150] Set column to 11 [0x0152] Extended opcode 4: set Discriminator to 1 [0x0156] Special opcode 215: advance Address by 15 to 0x4004e4 and Line by 0 to 5 [0x0157] Set column to 3 [0x0159] Extended opcode 4: set Discriminator to 1 [0x015d] Special opcode 89: advance Address by 6 to 0x4004ea and Line by 0 to 5 [0x015e] Set column to 10 [0x0160] Special opcode 65: advance Address by 4 to 0x4004ee and Line by 4 to 9 [0x0161] Set column to 1 [0x0163] Special opcode 76: advance Address by 5 to 0x4004f3 and Line by 1 to 10 [0x0164] Advance PC by 2 to 0x4004f5 [0x0166] Extended opcode 1: End of Sequence ... So, it seems gdb ignores the "recommended breakpoint location" at 0x4004cb, because there's an earlier one on the same line at 0x4004bc. The gdb approach is reasonable, but it could do better. It will be interesting to see how this example is handled by this ( https://sourceware.org/pipermail/gdb-patches/2020-May/168673.html ) gdb patch series.
[Bug debug/95360] inconsistent behaviors at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360 --- Comment #3 from Tom de Vries --- (In reply to Yibiao Yang from comment #0) > Breakpoint 1, main () at small.c:5 > 5 for (; d<1; d++) > (gdb) stepi > 0x004011545 for (; d<1; d++) > (gdb) stepi > 0x0040115a5 for (; d<1; d++) > (gdb) stepi > 0x0040115c5 for (; d<1; d++) > (gdb) stepi > 0x0040113b6 for (; b<1; b++) > (gdb) stepi > 0x004011416 for (; b<1; b++) > (gdb) stepi > 0x004011436 for (; b<1; b++) > (gdb) stepi > 7 c[b][d+1] = 0; > (gdb) > > > /* > As showed, Line 6 is hit first and then hit Line 7 with stepi. > However, when using step, gdb is first hit Line 7 and then hit Line 6. > This is an inconsistent behaviors between stepi and step > */ Gdb is behaving consistently in the following sense: - when gdb is at a "recommended breakpoint location" it shows the source line only with line number prefix. - otherwise, it shows the source line with both address and line number prefix. So, what the stepi sequence shows it that the next "recommended breakpoint location" after line 5 is line 7, which is consistent with a step from line 5 to line 7.
[Bug debug/95360] inconsistent behaviors at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1
[Bug debug/95360] inconsistent behaviors at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360 --- Comment #2 from Jonathan Wakely --- (In reply to Yibiao Yang from comment #0) > As showed, Line 6 is hit first and then hit Line 7 with stepi. > However, when using step, gdb is first hit Line 7 and then hit Line 6. > This is an inconsistent behaviors between stepi and step Why is that a bug? Why is it a GCC bug?
[Bug debug/95360] inconsistent behaviors at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360 --- Comment #1 from Yibiao Yang --- Created attachment 48616 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48616=edit the binary
