From: Matthew Gretton-Dann <matthew.gretton-dann@arm.com>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [rfc] Strip Thumb bit from PC returned by arm_get_longjmp_target
Date: Fri, 20 Aug 2010 08:38:00 -0000 [thread overview]
Message-ID: <1282293503.7290.8.camel@e102319-lin.cambridge.arm.com> (raw)
In-Reply-To: <201008190849.o7J8nEkP025126@d12av02.megacenter.de.ibm.com>
On Thu, 2010-08-19 at 10:49 +0200, Ulrich Weigand wrote:
> > Matthew Gretton-Dann wrote:
> >
> > > The problem with the patch is it removes what may be the only way we
> > > have of telling the instruction state of the longjmp target. If you
> > > have debugging information (mapping symbols at the very least)
> > > everything is fine, but if you don't then how do you tell what the state
> > > is? arm_pc_is_thumb does use this bit to detect the instruction state
> > > (and arm_breakpoint_from_pc then uses this result to determine the
> > > breakpoint type).
> >
> > Ah, I see. I was confused about just where the Thumb bit was supposed
> > to be present and where not, sorry ...
> >
> > > In the case above I think the correct fix is to make
> > > arm_adjust_breakpoint_address not strip out the address bits (which it
> > > does when trying to work out whether we are single stepping through an
> > > IT block).
> >
> > Does the patch below seem reasonable to you?
>
> Actually, it turns out this new patch doesn't work. It leads to:
>
> Breakpoint 4 at 0x84ec: file ../../../gdb-head/gdb/testsuite/gdb.threads/threxit-hop-specific.c, line 47.^M
> (gdb) next^M
> ^M
> Program received signal SIGTRAP, Trace/breakpoint trap.^M
>
> This happens because GDB now no longer recognizes the PC address
> when the breakpoint trap arrives. The PC is compared against
> the breakpoint location's loc->address value -- which now has the
> Thumb bit set, but the PC doesn't.
>
> Note that while the Thumb bit gets removes in arm_breakpoint_from_pc,
> this affects only loc->placed_address, not loc->address.
>
> This seems to indicate that in fact, breakpoint addresses must
> *not* have the Thumb bit set ...
>
> Do you have a case where this works for you?
I don't have a case. I think this means that the original patch is the
correct one for the moment - but I'm not a maintainer so this isn't an
approval.
Also, looking at the code in arm_adjust_breakpoint_address I think there
are other cases that may cause the failure you are seeing above (for
instance when using Thumb-2 in the absence of mapping symbols and
setting the breakpoint on 0x8001).
We still need to come up with a way to be able to better pass the
instruction set state around with the PC (I'll respond to your earlier
email with some of my thoughts).
Thanks,
Matt
--
Matthew Gretton-Dann
Principal Engineer - PDSW Tools
ARM Ltd
next prev parent reply other threads:[~2010-08-20 8:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-17 19:16 Ulrich Weigand
2010-08-18 9:01 ` Matthew Gretton-Dann
2010-08-18 18:28 ` Ulrich Weigand
2010-08-19 8:49 ` Ulrich Weigand
2010-08-20 8:38 ` Matthew Gretton-Dann [this message]
2010-08-20 12:00 ` Ulrich Weigand
2010-08-20 8:53 ` Matthew Gretton-Dann
2010-08-20 11:45 ` 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=1282293503.7290.8.camel@e102319-lin.cambridge.arm.com \
--to=matthew.gretton-dann@arm.com \
--cc=gdb-patches@sourceware.org \
--cc=uweigand@de.ibm.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).