Created attachment 12729 [details] GDB testsuite log file As reported on IRC, I'm seeing 6 FAIL's instead of the expected KFAIL's for this new test, exercised with today's master. FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1 FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 1st next FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2 FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 1st next FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next I'm running Ubuntu 18.04.4 with GCC 7.5.0. I've attached the log file.
Can we verify line number info first? On x86_64-linux, I see with readelf -wL: ... CU: dw2-line-number-zero.c: File name Line number Starting address View Stmt dw2-line-number-zero.c 27 0x4004b5 x dw2-line-number-zero.c 29 0x4004bf x dw2-line-number-zero.c 0 0x4004c9 x dw2-line-number-zero.c 33 0x4004d3 x dw2-line-number-zero.c 33 0x4004dd x dw2-line-number-zero.c 41 0x4004e4 x dw2-line-number-zero.c 43 0x4004ee x dw2-line-number-zero.c 0 0x4004f8 dw2-line-number-zero.c 47 0x400502 x dw2-line-number-zero.c 47 0x40050c x ... Can you post the output for aarch64?
I see the same for aarch64-linux: Contents of the .debug_line section: dw2-line-number-zero.c: File name Line number Starting address View dw2-line-number-zero.c 27 0x700 dw2-line-number-zero.c 29 0x708 dw2-line-number-zero.c 0 0x710 dw2-line-number-zero.c 33 0x718 dw2-line-number-zero.c 33 0x720 dw2-line-number-zero.c 41 0x734 dw2-line-number-zero.c 43 0x73c dw2-line-number-zero.c 0 0x744 dw2-line-number-zero.c 47 0x74c dw2-line-number-zero.c 47 0x754
Then my next question would be: why does this break land at address 0x708: ... (gdb) break bar1 Breakpoint 2 at 0xaaaaaaaaa708: file dw2-line-number-zero.c, line 29. ... ? From the disassembly in the log, we get: ... (gdb) disassemble bar1 Dump of assembler code for function bar1: 0x00000000000006f8 <+0>: stp x29, x30, [sp, #-16]! 0x00000000000006fc <+4>: mov x29, sp 0x0000000000000700 <+8>: mov w0, #0x1 // #1 0x0000000000000704 <+12>: bl 0x6e4 <foo> 0x0000000000000708 <+16>: mov w0, #0x2 // #2 0x000000000000070c <+20>: bl 0x6e4 <foo> 0x0000000000000710 <+24>: mov w0, #0x3 // #3 0x0000000000000714 <+28>: bl 0x6e4 <foo> 0x0000000000000718 <+32>: mov w0, #0x4 // #4 0x000000000000071c <+36>: bl 0x6e4 <foo> 0x0000000000000720 <+40>: nop 0x0000000000000724 <+44>: ldp x29, x30, [sp], #16 0x0000000000000728 <+48>: ret End of assembler dump. ... Why don't we stop before the first call to foo, at 0x700, line 27?
I'm not sure. What does the test want to do? Stop at where GDB thinks bar1's prologue ends, stop at bar1's first instruction or stop at a particular line number? The compiler can sometimes move things. I didn't go through the testcase to understand what it is trying to do yet, but can do so if you think that is helpful.
(In reply to Luis Machado from comment #4) > I'm not sure. What does the test want to do? Stop at where GDB thinks bar1's > prologue ends, stop at bar1's first instruction or stop at a particular line > number? > Roughly I want the break to do the same as: ... $ gcc -g dw2-line-number-zero.c $ gdb -q a.out Reading symbols from a.out... (gdb) b bar1 Breakpoint 1 at 0x4004a5: file dw2-line-number-zero.c, line 27. (gdb) r Starting program: a.out Breakpoint 1, bar1 () at dw2-line-number-zero.c:27 27 foo (1); ... My guess of what should happen when setting a break on bar1 is: - determine first insn after prologue (that would be 0x700) - look in line number info for first line associated with that or a subsequent insn (that would be line 27 for 0x700) - set the breakpoint at line/address (27/0x700) Anyway, what I want is for the test to stop at line 27/bar1_label, so this would work: ... return -1 } -gdb_breakpoint "bar1" +gdb_breakpoint "bar1:27" gdb_continue_to_breakpoint "bar1" "\[^\r\n\]*:27\r\n.*" gdb_test "n" "foo \\(2\\);" "bar1, 1st next" gdb_test "n" "foo \\(4\\);" "bar1, 2nd next" -gdb_breakpoint "bar2" +gdb_breakpoint "bar2:41" gdb_continue_to_breakpoint "bar2" "\[^\r\n\]*:41\r\n.*" gdb_test "n" "foo \\(2\\);" "bar2, 1st next" ... or alternatively: ... return -1 } -gdb_breakpoint "bar1" +gdb_breakpoint "bar1_label" gdb_continue_to_breakpoint "bar1" "\[^\r\n\]*:27\r\n.*" gdb_test "n" "foo \\(2\\);" "bar1, 1st next" gdb_test "n" "foo \\(4\\);" "bar1, 2nd next" -gdb_breakpoint "bar2" +gdb_breakpoint "bar2_label" gdb_continue_to_breakpoint "bar2" "\[^\r\n\]*:41\r\n.*" gdb_test "n" "foo \\(2\\);" "bar2, 1st next" ... Could you give these a try? > The compiler can sometimes move things. I didn't go through the testcase to > understand what it is trying to do yet, but can do so if you think that is > helpful. I think you need to decide whether something needs fixing for aarch64.
(In reply to Tom de Vries from comment #5) > > The compiler can sometimes move things. I didn't go through the testcase to > > understand what it is trying to do yet, but can do so if you think that is > > helpful. > > I think you need to decide whether something needs fixing for aarch64. The scenario can be exercised with: ... $ gdb --args gdb -batch dw2-line-number-zero -ex "b bar1" ... My guess is that the interesting bit can be viewed by putting a breakpoint on skip_prologue_sal.
Right. I'm following that code at the moment to see why it isn't stopping before the branch. The branch is a stopping condition, but the move before that should've also caused a stop.
I think there is a hidden bug in the prologue analyzer for aarch64 and this testcase just happened to expose it given it uses movz. The current code assumes movz is part of the prologue, but it does not seem to be used that often (or at all) for that purpose. Therefore this doesn't seem to be a problem with the testcase. Thanks for your clarifications on the purpose of the test.
(In reply to Luis Machado from comment #8) > I think there is a hidden bug in the prologue analyzer for aarch64 and this > testcase just happened to expose it given it uses movz. The current code > assumes movz is part of the prologue, but it does not seem to be used that > often (or at all) for that purpose. > Aha, that explains it. Thanks for looking into this. > Therefore this doesn't seem to be a problem with the testcase. Thanks for > your clarifications on the purpose of the test. I've refiled the problem described above as tdep PR: PR26310 - "[aarch64] Prologue analyzer considers user code part of prologue".