This is the mail archive of the
mailing list for the GDB project.
Re: RFC: remove gdbarch from struct breakpoint
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: tromey at redhat dot com (Tom Tromey)
- Cc: pedro at codesourcery dot com (Pedro Alves), gdb-patches at sourceware dot org, brobecker at adacore dot com (Joel Brobecker)
- Date: Tue, 8 Nov 2011 18:18:49 +0100 (CET)
- Subject: Re: RFC: remove gdbarch from struct breakpoint
Tom Tromey wrote:
> >>>>> "Ulrich" == Ulrich Weigand <email@example.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.
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE