From: Bruno Larsen <blarsen@redhat.com>
To: Carl Love <cel@us.ibm.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Cc: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Subject: Re: [PATCH] Fix test next-reverse-bkpt-over-sr.exp
Date: Wed, 28 Sep 2022 09:35:15 +0200 [thread overview]
Message-ID: <69b2451b-1baf-8bd4-25dd-a1b46963981f@redhat.com> (raw)
In-Reply-To: <e0f721cd4a34b242d7046d7823be04aeb54efdd7.camel@us.ibm.com>
On 27/09/2022 18:14, Carl Love via Gdb-patches wrote:
> GDB maintainers:
>
> The next-reverse-bkpt-over-sr.exp test sets a breakpoint on *callee.
> The intention is the test is setting a breakpoint on the entry point of
> the function. However on PowerPC, the statement sets the breakpoint on
> the global entry point. The test uses the local entry point to the
> function callee and thus the breakpoint on the global entry point is
> never hit resulting in the test failing.
>
> This patch changes the break instruction to callee to properly set the
> breakpoint.
>
> The patch has been tested on both Power10 and X86-64 with no regression
> errors.
>
> Please let me know if this patch is acceptable for mainline. Thanks.
>
> Carl Love
>
Hi Carl,
I don't think this change is acceptable. Looking at the comment at the
top of next-reverse-bkpt-over-sr.exp, we see the following:
# reverse-next over a function call sets a step-resume breakpoint at
# callee's entry point, runs to it, and then does an extra single-step
# to get at the callee's caller. Test that a user breakpoint set at
# the same location as the step-resume breakpoint isn't ignored.
Based on this, the test seems to expect that a user has placed the
breakpoint at the exact same instruction as where GDB will place the
step-resume breakpoint.
By getting GDB to print where it is placing the step-resume breakpoint
(using the patch at the end of this email), and running the test
manually to see where breakpoints are located when using "break callee"
and "break *callee", I get the following output:
(gdb) rn
setting step_resume_breakpoint at 0x401136
55 callee(); /* NEXT OVER THIS CALL */
(gdb) b callee
Breakpoint 2 at 0x40113a: file
/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.reverse/step-reverse.c,
line 26.
(gdb) b *callee
Breakpoint 3 at 0x401136: file
/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.reverse/step-reverse.c,
line 25.
As you can see, setting a breakpoint at callee does not create a user
breakpoint at the same instruction as the step-resume breakpoint in
x86_64 processors, rendering this test useless.
I encourage you to try the same patch I used to get the location for the
step-resume breakpoint on powerpc architectures, and if they turn out to
be the same, maybe you can make an architecture check at the top of this
test, changing the location of the breakpoint based on it.
Cheers,
Bruno
diff --git a/gdb/infrun.c b/gdb/infrun.c
index 1957e8020dd..1699f4a0c6c 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -7130,6 +7130,7 @@ process_event_stop_test (struct
execution_control_state *ecs)
{
/* Normal function call return (static or dynamic). */
symtab_and_line sr_sal;
+ gdb_printf ("setting step_resume_breakpoint at
0x%lx\n", ecs->stop_func_start);
sr_sal.pc = ecs->stop_func_start;
sr_sal.pspace = get_frame_program_space (frame);
insert_step_resume_breakpoint_at_sal (gdbarch,
next prev parent reply other threads:[~2022-09-28 7:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-27 16:14 Carl Love
2022-09-28 7:35 ` Bruno Larsen [this message]
2022-11-14 21:05 ` [PATCH] PowerPC, fix gdb.reverse/finish-reverse-bkpt.exp and gdb.reverse/next-reverse-bkpt-over-sr.exp Carl Love
2022-11-21 16:36 ` [PING] " Carl Love
2022-11-22 9:42 ` Bruno Larsen
2022-11-22 16:53 ` Carl Love
2022-11-23 8:44 ` Bruno Larsen
2022-11-23 17:56 ` Ulrich Weigand
2022-11-23 23:33 ` Carl Love
2022-11-28 18:52 ` Carl Love
2022-11-29 8:52 ` Bruno Larsen
2022-11-29 16:50 ` Carl Love
2022-11-29 16:57 ` [PATCH V4] " Carl Love
2022-11-30 11:30 ` Ulrich Weigand
2022-12-01 1:33 ` Carl Love
2022-12-01 15:50 ` [PATCH V5] " Carl Love
2022-12-01 16:02 ` Ulrich Weigand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=69b2451b-1baf-8bd4-25dd-a1b46963981f@redhat.com \
--to=blarsen@redhat.com \
--cc=Ulrich.Weigand@de.ibm.com \
--cc=cel@us.ibm.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).