From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: tromey@redhat.com (Tom Tromey)
Cc: pedro@codesourcery.com (Pedro Alves),
gdb-patches@sourceware.org,
brobecker@adacore.com (Joel Brobecker)
Subject: Re: RFC: remove gdbarch from struct breakpoint
Date: Tue, 08 Nov 2011 17:19:00 -0000 [thread overview]
Message-ID: <201111081718.pA8HInH6022772@d06av02.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <m3y5vqim8c.fsf@fleche.redhat.com> from "Tom Tromey" at Nov 08, 2011 09:59:31 AM
Tom Tromey wrote:
> >>>>> "Ulrich" == Ulrich Weigand <uweigand@de.ibm.com> writes:
>
> Ulrich> Most other architecture-dependent things in breakpoint.c etc really
> Ulrich> should use a per-location architecture. However, the way the per-
> Ulrich> location arch is currently chosen is to either determine it from
> Ulrich> the location --but this works only if we find a symtab!-- or else
> Ulrich> fall back to the main breakpoint architecture. If we remove that
> Ulrich> fall back, there will be cases where breakpoints are set at locations
> Ulrich> with no symtab (e.g. in generated code, stack trampolines, etc.)
> Ulrich> and we will not find any associated architecture.
>
> Ok, I see.
>
> Why not just use the location's arch when parsing and re-parsing the
> expression, though?
Well, which location? A single breakpoint might expand to multiple
locations in different architectures, any or none of which might
be the same as the current architecture at the time the breakpoint
is initially entered ...
For example, today we could add a breakpoint like:
break spu.c:123 if var.offset == 123
while currently in PowerPC architecture. The way this was intended
to work is to set a breakpoint location on spu.c:123 (with a location
architecture of "spu"), while evaluating the condition using
PowerPC architecture settings.
> With my patches this still defaults to the current
> arch when the breakpoint is set -- this just isn't stored on the
> breakpoint any more.
Actually, it doesn't: the location arch is retrieved from the SAL,
it only falls back to the current arch if there is no architecture
associated with the SAL. So in the case mentioned above, the
location arch would be set to "spu", and the fact that the current
arch was "powerpc" when the breakpoint was set would be lost.
> (Now get_sal_arch tries to get the objfile arch as
> a fallback, which I hope avoids any missing cases.)
Well, in the cases I mentioned above (generated code, stack trampolines)
-- which are rare, but possible, breakpoint targets, especially for
single-step breakpoints -- there is no objfile either.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2011-11-08 17:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-27 15:21 Tom Tromey
2011-11-07 15:21 ` Joel Brobecker
2011-11-07 16:10 ` Pedro Alves
2011-11-07 16:52 ` Stan Shebs
2011-11-08 16:22 ` Ulrich Weigand
2011-11-08 17:00 ` Tom Tromey
2011-11-08 17:19 ` Ulrich Weigand [this message]
2011-11-08 18:10 ` Tom Tromey
2011-11-09 18:22 ` Tom Tromey
2011-11-14 16:10 ` FYI: tracepoints and multi-arch (Was: RFC: remove gdbarch from struct breakpoint) Tom Tromey
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=201111081718.pA8HInH6022772@d06av02.portsmouth.uk.ibm.com \
--to=uweigand@de.ibm.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=pedro@codesourcery.com \
--cc=tromey@redhat.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