From: Bruno Larsen <blarsen@redhat.com>
To: Carl Love <cel@us.ibm.com>,
Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
"luis.machado@arm.com" <luis.machado@arm.com>
Subject: Re: Questions on how best to fix two gdb tests gdb.reverse/finish-reverse-bkpt.exp and gdb.reverse/next-reverse-bkpt-over-sr.exp
Date: Mon, 26 Sep 2022 18:08:46 +0200 [thread overview]
Message-ID: <bc39c861-c7a0-4ff2-6ab1-249703484f5e@redhat.com> (raw)
In-Reply-To: <4bb7ce2d41f5623a8866a9e631e3cda48a6a0e04.camel@us.ibm.com>
On 26/09/2022 17:30, Carl Love via Gdb-patches wrote:
> Ulrich, Luis:
>
> On Mon, 2022-09-26 at 14:36 +0000, Ulrich Weigand wrote:
>> Luis Machado <luis.machado@arm.com> wrote:
>>
>>> gdbarch has a hook to adjust the breakpoint address
>>> (gdbarch_adjust_breakpoint_address). Can this be used to bend
>>> commands
>>> like "b *func" so they behave the same as other architectures?
>> I don't think this works. The problem is that "b *func" is a weird
>> hack that combines two aspects: use of "func" as a value that at this
>> point is just a plain symbol table lookup; and use of "*" to set a
>> breakpoint at an explicitly specified absolute address.
>>
>> Neither of these aspects is something we want to change on its own.
>> We do want a plain symbol, if used as a value, to return the
>> address that is in the symbol table. Everything else would just
>> be confusing, and could also break things if "if ptr == func"
>> where "ptr" is a function pointer variable.
>>
>> On the other hand, when using "b *<addr>" with some hard-coded
>> address, we actually want the breakpoint to be exactly there
>> and nowhere else; that is usually used by someone familiar with
>> the platform who want to set the breakpoint exactly there. (Or,
>> possibly, by clicking on "set breakpoint" in a GUI switched to
>> the assembly view.) Automatically moving this to a different
>> address would be weird, when the whole point of "*" is that it
>> *isn't* trying to be clever, unlike say "b func".
>>
>> It is an unfortunate fact that these two properties, which are
>> each desired on their own, combine to yield an undesirable
>> effect when used as "b *func" on Power. But I think the root
>> cause of this is that "b *func" is used here in a way that is
>> not justified by the actual specification of those features.
>>
>> Actually, I'm not seeing much use of this particular construct
>> at all, outside of the GDB test suite. And here, it is used
>> in the idiosyncratic manner of "do a 'b func' but just without
>> skipping the prolog", usually because of some GDB test suite
>> internal reason why we want to avoid prolog skipping just here.
>>
>> It seems to me that the real fix would be some new syntax that
>> makes this goal explicit, maybe along the lines of
>> b -entrypoint func
>>
>> (It would still be preferable to me to investigate use of this
>> construct throughout the test suite to see if it is *really*
>> necessary or if the tests can simply be rewritten in a way
>> that they don't need the "skip prolog" feature anyway ...)
> I looked at the suggestion from Luis. In the end, I really didn't
> think changing gdb to make the test work is really the best idea. The
> issue is that there are cases, as Ulrich said, where someone who knows
> the details may actually want to set the breakpoint on the first
> instruction. If I change gdb, to fix the test by "adjusting" the
> desired breakpoint then the user is no longer able to stop where they
> want to.
>
> I am not sure why the original test was concerned about the prolog.
> The original author doesn't seem to be around anymore. I will think
> about how to change the first test some more.
From what I could see in the comments of the test, the problem was that
reverse-finishing out of the function would ignore breakpoints that were
set before the prologue.
In case you aren't familiar with how GDB does a reverse-finish (and
sorry if you are), it decides what is the first instruction executed in
the current frame, places a breakpoint there, and reverse-continues
until that breakpoint is hit. GDB then removes that breakpoint and does
a reverse-stepi to leave the function call.
If there was already a user breakpoint at that instruction, GDB should
_not_ do the reverse-stepi. For this test, it seems imperative that the
breakpoint is placed before the prologue, since it is where GDB would
place the step-resume-breakpoint that reverse-finish uses.
>
> I don't see any issues with changing the second test to just break on
> the function callee rather than *callee. I will submit a patch to
> change the second test.
Same goes for the second test. It explicitly states that GDB was
removing the user-placed breakpoint if it was placed at the exact same
instruction as step-resume-breakpoint would be hit, so moving the
breakpoint to after the prologue would render the test useless, as the
bug conditions wouldn't be met anymore.
What you probably want to do in both cases is find a way to get the
addresses of the functions and set a breakpoint there as "b *(address)"
instead, though I'm not sure how I'd suggest you do it.
Cheers,
Bruno
>
> Carl
>
prev parent reply other threads:[~2022-09-26 16:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-22 18:23 Carl Love
2022-09-23 9:13 ` Bruno Larsen
2022-09-23 10:48 ` Luis Machado
2022-09-23 10:56 ` Luis Machado
2022-09-26 14:36 ` Ulrich Weigand
2022-09-26 15:30 ` Carl Love
2022-09-26 16:08 ` Bruno Larsen [this message]
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=bc39c861-c7a0-4ff2-6ab1-249703484f5e@redhat.com \
--to=blarsen@redhat.com \
--cc=Ulrich.Weigand@de.ibm.com \
--cc=cel@us.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=luis.machado@arm.com \
/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).