* [PATCH] [gdb/testsuite] Fix gdb.dwarf2/dw2-entry-points.exp on ppc64le @ 2024-01-11 12:42 Tom de Vries 2024-01-11 12:55 ` Guinevere Larsen 2024-01-11 15:01 ` Ulrich Weigand 0 siblings, 2 replies; 5+ messages in thread From: Tom de Vries @ 2024-01-11 12:42 UTC (permalink / raw) To: gdb-patches; +Cc: Ulrich Weigand, Carl Love On ppc64le-linux, I run into: ... (gdb) bt^M #0 0x00000000100006dc in foobar (J=2)^M #1 0x000000001000070c in prog ()^M (gdb) FAIL: gdb.dwarf2/dw2-entry-points.exp: bt foo ... The test-case attemps to emulate additional entry points of a function, with function bar having entry points foo and foobar: ... (gdb) p bar $1 = {void (int, int)} 0x1000064c <bar> (gdb) p foo $2 = {void (int, int)} 0x10000698 <foo> (gdb) p foobar $3 = {void (int)} 0x100006d0 <foobar> ... However, when setting a breakpoint on the entry point foo: ... (gdb) b foo Breakpoint 1 at 0x100006dc ... it ends up in foobar instead of in foo, due to prologue skipping, and consequently the backtrace show foobar instead foo. The problem is that the test-case does not emulate an actual prologue at each entry point. Fix this by disabling the prologue skipping when setting a breakpoint, using "break *foo". Tested on ppc64le-linux and x86_64-linux. PR testsuite/31232 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31232 --- gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp b/gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp index f361820f72f..035b15ee087 100644 --- a/gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp +++ b/gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp @@ -180,8 +180,8 @@ if ![runto_main] { } # Try whether we can set and hit breakpoints at the entry_points. -gdb_breakpoint "foo" -gdb_breakpoint "foobar" +gdb_breakpoint "*foo" +gdb_breakpoint "*foobar" # Now hit the entry_point break point and check their call-stack. gdb_continue_to_breakpoint "foo" @@ -204,7 +204,7 @@ if ![runto_main] { return -1 } -gdb_breakpoint "fooso" +gdb_breakpoint "*fooso" gdb_continue_to_breakpoint "foo_so" gdb_test "bt" [multi_line \ base-commit: 4ece39c56cfdd5647d4061f3c084b9de6f9e443c -- 2.35.3 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] [gdb/testsuite] Fix gdb.dwarf2/dw2-entry-points.exp on ppc64le 2024-01-11 12:42 [PATCH] [gdb/testsuite] Fix gdb.dwarf2/dw2-entry-points.exp on ppc64le Tom de Vries @ 2024-01-11 12:55 ` Guinevere Larsen 2024-01-11 13:08 ` Tom de Vries 2024-01-11 15:01 ` Ulrich Weigand 1 sibling, 1 reply; 5+ messages in thread From: Guinevere Larsen @ 2024-01-11 12:55 UTC (permalink / raw) To: Tom de Vries, gdb-patches; +Cc: Ulrich Weigand, Carl Love On 11/01/2024 13:42, Tom de Vries wrote: > On ppc64le-linux, I run into: > ... > (gdb) bt^M > #0 0x00000000100006dc in foobar (J=2)^M > #1 0x000000001000070c in prog ()^M > (gdb) FAIL: gdb.dwarf2/dw2-entry-points.exp: bt foo > ... > > The test-case attemps to emulate additional entry points of a function, with > function bar having entry points foo and foobar: > ... > (gdb) p bar > $1 = {void (int, int)} 0x1000064c <bar> > (gdb) p foo > $2 = {void (int, int)} 0x10000698 <foo> > (gdb) p foobar > $3 = {void (int)} 0x100006d0 <foobar> > ... > > However, when setting a breakpoint on the entry point foo: > ... > (gdb) b foo > Breakpoint 1 at 0x100006dc > ... > it ends up in foobar instead of in foo, due to prologue skipping, and > consequently the backtrace show foobar instead foo. > > The problem is that the test-case does not emulate an actual prologue at each > entry point. > > Fix this by disabling the prologue skipping when setting a breakpoint, using > "break *foo". Sorry if my question doesn't make sense, but wouldn't we also want to verify that prologue skipping works correctly in a function with multiple entrypoints? I agree that this looks like a testsuite fail rather than a real GDB bug, but I feel like we'll be losing a valuable test if we don't try it at any point, especially now that it is easy to explicitly mark an instruction as EPILOGUE_END in the dwarf assembler. -- Cheers, Guinevere Larsen She/Her/Hers > > Tested on ppc64le-linux and x86_64-linux. > > PR testsuite/31232 > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31232 > --- > gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp b/gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp > index f361820f72f..035b15ee087 100644 > --- a/gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp > +++ b/gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp > @@ -180,8 +180,8 @@ if ![runto_main] { > } > > # Try whether we can set and hit breakpoints at the entry_points. > -gdb_breakpoint "foo" > -gdb_breakpoint "foobar" > +gdb_breakpoint "*foo" > +gdb_breakpoint "*foobar" > > # Now hit the entry_point break point and check their call-stack. > gdb_continue_to_breakpoint "foo" > @@ -204,7 +204,7 @@ if ![runto_main] { > return -1 > } > > -gdb_breakpoint "fooso" > +gdb_breakpoint "*fooso" > gdb_continue_to_breakpoint "foo_so" > > gdb_test "bt" [multi_line \ > > base-commit: 4ece39c56cfdd5647d4061f3c084b9de6f9e443c ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] [gdb/testsuite] Fix gdb.dwarf2/dw2-entry-points.exp on ppc64le 2024-01-11 12:55 ` Guinevere Larsen @ 2024-01-11 13:08 ` Tom de Vries 2024-01-11 13:33 ` Guinevere Larsen 0 siblings, 1 reply; 5+ messages in thread From: Tom de Vries @ 2024-01-11 13:08 UTC (permalink / raw) To: Guinevere Larsen, gdb-patches; +Cc: Ulrich Weigand, Carl Love On 1/11/24 13:55, Guinevere Larsen wrote: > On 11/01/2024 13:42, Tom de Vries wrote: >> On ppc64le-linux, I run into: >> ... >> (gdb) bt^M >> #0 0x00000000100006dc in foobar (J=2)^M >> #1 0x000000001000070c in prog ()^M >> (gdb) FAIL: gdb.dwarf2/dw2-entry-points.exp: bt foo >> ... >> >> The test-case attemps to emulate additional entry points of a >> function, with >> function bar having entry points foo and foobar: >> ... >> (gdb) p bar >> $1 = {void (int, int)} 0x1000064c <bar> >> (gdb) p foo >> $2 = {void (int, int)} 0x10000698 <foo> >> (gdb) p foobar >> $3 = {void (int)} 0x100006d0 <foobar> >> ... >> >> However, when setting a breakpoint on the entry point foo: >> ... >> (gdb) b foo >> Breakpoint 1 at 0x100006dc >> ... >> it ends up in foobar instead of in foo, due to prologue skipping, and >> consequently the backtrace show foobar instead foo. >> >> The problem is that the test-case does not emulate an actual prologue >> at each >> entry point. >> >> Fix this by disabling the prologue skipping when setting a breakpoint, >> using >> "break *foo". > > Sorry if my question doesn't make sense, but wouldn't we also want to > verify that prologue skipping works correctly in a function with > multiple entrypoints? > Agreed, ideally we'd also verify it in this test-case. However, the commit introducing support for this also adds a test-case gdb.fortran/entry-point.exp which does verify that part of the functionality with compiler-generated entry points and prologues. > I agree that this looks like a testsuite fail rather than a real GDB > bug, but I feel like we'll be losing a valuable test if we don't try it > at any point, especially now that it is easy to explicitly mark an > instruction as EPILOGUE_END in the dwarf assembler. > I suppose you mean prologue_end (and I hadn't thought of that, thanks for the suggestion), but yes, we could do this. It would require adding a .debug_line section in the dwarf assembly, something that is currently missing. But given that the other test-case already tests this functionality, I'm not sure if it's worth the effort. Thanks, - Tom ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] [gdb/testsuite] Fix gdb.dwarf2/dw2-entry-points.exp on ppc64le 2024-01-11 13:08 ` Tom de Vries @ 2024-01-11 13:33 ` Guinevere Larsen 0 siblings, 0 replies; 5+ messages in thread From: Guinevere Larsen @ 2024-01-11 13:33 UTC (permalink / raw) To: Tom de Vries, gdb-patches; +Cc: Ulrich Weigand, Carl Love On 11/01/2024 14:08, Tom de Vries wrote: > On 1/11/24 13:55, Guinevere Larsen wrote: >> On 11/01/2024 13:42, Tom de Vries wrote: >>> On ppc64le-linux, I run into: >>> ... >>> (gdb) bt^M >>> #0 0x00000000100006dc in foobar (J=2)^M >>> #1 0x000000001000070c in prog ()^M >>> (gdb) FAIL: gdb.dwarf2/dw2-entry-points.exp: bt foo >>> ... >>> >>> The test-case attemps to emulate additional entry points of a >>> function, with >>> function bar having entry points foo and foobar: >>> ... >>> (gdb) p bar >>> $1 = {void (int, int)} 0x1000064c <bar> >>> (gdb) p foo >>> $2 = {void (int, int)} 0x10000698 <foo> >>> (gdb) p foobar >>> $3 = {void (int)} 0x100006d0 <foobar> >>> ... >>> >>> However, when setting a breakpoint on the entry point foo: >>> ... >>> (gdb) b foo >>> Breakpoint 1 at 0x100006dc >>> ... >>> it ends up in foobar instead of in foo, due to prologue skipping, and >>> consequently the backtrace show foobar instead foo. >>> >>> The problem is that the test-case does not emulate an actual >>> prologue at each >>> entry point. >>> >>> Fix this by disabling the prologue skipping when setting a >>> breakpoint, using >>> "break *foo". >> >> Sorry if my question doesn't make sense, but wouldn't we also want to >> verify that prologue skipping works correctly in a function with >> multiple entrypoints? >> > > Agreed, ideally we'd also verify it in this test-case. > > However, the commit introducing support for this also adds a test-case > gdb.fortran/entry-point.exp which does verify that part of the > functionality with compiler-generated entry points and prologues. > >> I agree that this looks like a testsuite fail rather than a real GDB >> bug, but I feel like we'll be losing a valuable test if we don't try >> it at any point, especially now that it is easy to explicitly mark an >> instruction as EPILOGUE_END in the dwarf assembler. >> > > I suppose you mean prologue_end (and I hadn't thought of that, thanks > for the suggestion), but yes, we could do this. It would require > adding a .debug_line section in the dwarf assembly, something that is > currently missing. oops, yes sorry, prologue_end. Working on the epilogue_begin stuff has me mixing the 2 words all the time hahaha > > But given that the other test-case already tests this functionality, > I'm not sure if it's worth the effort. Yeah, I think I agree with you here that if a testcase already verifies that, going through the trouble of adding the whole lines section is not worth it. FWIW, patch doesn't introduce any regressions on my x86, f39 machine, Tested-By: Guinevere Larsen <blarsen@redhat.com> -- Cheers, Guinevere Larsen She/Her/Hers ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] [gdb/testsuite] Fix gdb.dwarf2/dw2-entry-points.exp on ppc64le 2024-01-11 12:42 [PATCH] [gdb/testsuite] Fix gdb.dwarf2/dw2-entry-points.exp on ppc64le Tom de Vries 2024-01-11 12:55 ` Guinevere Larsen @ 2024-01-11 15:01 ` Ulrich Weigand 1 sibling, 0 replies; 5+ messages in thread From: Ulrich Weigand @ 2024-01-11 15:01 UTC (permalink / raw) To: gdb-patches, tdevries; +Cc: cel Tom de Vries <tdevries@suse.de> wrote: >The test-case attemps to emulate additional entry points of a function, with >function bar having entry points foo and foobar: [...] >Fix this by disabling the prologue skipping when setting a breakpoint, using >"break *foo". Normally I don't like to introduce "break *..." because it ignores the ppc64le ELFv2 local/global entry point distinction. But in this particular case, this distinction doesn't apply anyway as the extra entry points are synthetic and don't have local versions. So I think this should be OK. Thanks, Ulrich ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-01-11 15:01 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-01-11 12:42 [PATCH] [gdb/testsuite] Fix gdb.dwarf2/dw2-entry-points.exp on ppc64le Tom de Vries 2024-01-11 12:55 ` Guinevere Larsen 2024-01-11 13:08 ` Tom de Vries 2024-01-11 13:33 ` Guinevere Larsen 2024-01-11 15:01 ` Ulrich Weigand
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).