From: Pedro Alves <palves@redhat.com>
To: "Maciej W. Rozycki" <macro@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] remote: Fix hw watchpoint address matching
Date: Tue, 06 Mar 2012 18:56:00 -0000 [thread overview]
Message-ID: <4F565A23.1070009@redhat.com> (raw)
In-Reply-To: <alpine.DEB.1.10.1202242301170.4811@tp.orcam.me.uk>
On 02/24/2012 11:48 PM, Maciej W. Rozycki wrote:
> Hi Pedro,
>
> Back to this change, was distracted by something else.
So was I. :-)
>>> This makes me nervous. I think we should be liberal on what we accept.
>>> In particular ILP32 ABIs on 64-bit targets may be affected. An example is
>>> the MIPS n64 ABI where the width of general registers is 64 bits and
>>> addresses are sign-extended 32 bits. When bit #31 is set in the address,
>>> the remote stub may possibly report the value as truncated to 32 bits or
>>> as a properly sign-extended 64-bit value. Not that I observed this
>>> anywhere, but I think we should accept both.
>>
>> If such thing were possible, then wouldn't breakpoints break?
>> We store the (masked) address of where we ended up putting
>> the breakpoint in bp_tgt->placed_address (remote_insert_breakpoint),
>> and if the target reported an address not exactly bp_tgt->placed_address,
>> we wouldn't be able to match it up, resulting in spurious SIGTRAPs.
>> Hmm, actually, it looks like breakpoint.c:bkpt_breakpoint_hit is broken
>> in that it should be using bl->target_info.placed_address instead
>> of bl->address ? How is this not breaking on cases that need
>> breakpoint adjustment? I'm probably missing something.
>
> Yes, this is about watchpoints, not breakpoints. ;)
I fully understand that. What I was saying is that if that is a concern,
then breakpoints with bit #31 set are quite likely to suffer from exactly
the same issue, with the remote possibly reporting the trapped address as
truncated to 32 bits or as a properly sign-extended 64-bit value. And I'd
imagine the code that handles the low level traps/exceptions to handle
both watchpoint and breakpoint addresses the same, and the stub code that
marshals those breakpoint addresses to rsp to be just as susceptible to
the issue as code that marshals watchpoint addresses. Now, I'm not
saying we should run to fix that...
I'm still curious why isn't bkpt_breakpoint_hit broken like I described
above, when a breakpoint is subject to adjustment, such as
that done by mips_breakpoint_from_pc. I probably need to stare more
at the code. ;-)
>> /* Implementation of target method FOO. */
>
> Umm, there aren't that many comments of this kind there actually...
We started enforcing that rule not too long ago.
Anyway, thanks for the fixes, and congratulations on your new role. :-)
--
Pedro Alves
next prev parent reply other threads:[~2012-03-06 18:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-30 18:24 Maciej W. Rozycki
2011-12-07 17:55 ` Pedro Alves
2011-12-07 23:36 ` Maciej W. Rozycki
2011-12-09 14:34 ` Pedro Alves
2012-02-25 1:54 ` Maciej W. Rozycki
2012-03-06 18:56 ` Pedro Alves [this message]
2012-03-06 20:20 ` Maciej W. Rozycki
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=4F565A23.1070009@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=macro@codesourcery.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