public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: matthew.gretton-dann@arm.com (Matthew Gretton-Dann)
Cc: gdb-patches@sourceware.org
Subject: Re: [rfc] Strip Thumb bit from PC returned by arm_get_longjmp_target
Date: Fri, 20 Aug 2010 12:00:00 -0000	[thread overview]
Message-ID: <201008201200.o7KC0ASe007759@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <1282293503.7290.8.camel@e102319-lin.cambridge.arm.com> from "Matthew Gretton-Dann" at Aug 20, 2010 09:38:23 AM

Matthew Gretton-Dann wrote:
> On Thu, 2010-08-19 at 10:49 +0200, Ulrich Weigand wrote:
> > 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.  

OK, thanks for your feedback.  I'm happy to wait for Richard's 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).

I'm now wondering whether it can in fact ever happen that an address with
the Thumb bit set can come into arm_adjust_breakpoint_address; it seems
that (except for the longjmp target case) no such values are ever exposed.
Am I missing a possible path here?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

  reply	other threads:[~2010-08-20 12:00 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
2010-08-20 12:00         ` Ulrich Weigand [this message]
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=201008201200.o7KC0ASe007759@d12av02.megacenter.de.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=matthew.gretton-dann@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).