This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [0/2] Inspect extra signal information
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Cc: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- Date: Tue, 3 Feb 2009 18:23:06 +0000
- Subject: Re: [0/2] Inspect extra signal information
- References: <200902031642.n13GgL35026175@d12av02.megacenter.de.ibm.com>
On Tuesday 03 February 2009 16:42:21, Ulrich Weigand wrote:
> Pedro Alves wrote:
> > But, I thought I had, but I clearly didn't test before:
> >
> > - 64-bit gdb x 32-bit inferior, 64-bit kernel
> >
> > siginfo comes out with the 64-bit layout.
> > ^^^^^^
>
> Huh. With bi-arch setups, I understand everything is currently
> supposed to be set up so that debugging a 32-bit program
> with a 64-bit GDB looks just the same as debugging it
> with a 32-bit GDB.
>
> The above would break that assumption: you see different
> types of siginfo depending on your host GDB. I'm not sure
> if that is really what we want ...
Right, I'm not sure either.
> On the other hand, it's going to be difficult to avoid. One
> way would be for the Linux native target to always return
> the 32-bit layout when debugging a 32-bit inferior; if necessary
> it would have to convert the data in-place before returning it
> (similar to how the native target today converts register contents
> to 32 bit even though the ptrace interface returns 64 bit values).
I guess I should try this.
> > I was looking at target_gdbarch, and it doesn't seem to fit the
> > bill either. E.g., a biarch ppc64 gdbserver returns a 32-bit
> > target_arch if the inferior is 32-bit.
>
> That's actually an interesting question. The idea behind
> "target_gdbarch" is "the architecture implemented by the
> target debugger interface". In a bi-arch setup, the target
> today emulates a 32-bit target interface when debugging a 32-bit
> inferior, even when GDB itself is 64-bit. This is done by
> explicit conversion in the native target (see above).
The only weird case I can think of, if when you have an
inferior that can do mode switching, and the siginfo_t type
is different in different modes. In this case, there'd better
be a single siginfo_t layout for all modes, otherwise you get
funny cases. Say, a signal handler installed in code that runs
mode x-bit, but the signal was raised while running code
in mode y-bit. Without kernel help, GDB can't know the correct
layout of the siginfo_t object the inferior will see in the
signal handler.
I don't think we can see that happen on linux, though, so on
the fly conversion out of ptrace sounds like a good option.
Let's see if it doesn't come out looking too ugly. If I make
use of struct type/struct value if may not be bad, but, gdbserver
can't use those...
> Before real multi-architecture support, there really was to
> other way to do it. However, once we get to full multi-arch,
> it might in fact be a more natural fit to model the bi-arch
> setup by having "target_gdbarch" indicate the actual bitness
> of the ptrace interface (i.e. 64-bit), while still setting
> the per-frame architecture of all frames to the appropriate
> 32-bit architecture ... This might allow us to get rid of
> some of the bi-arch special hacks in native target code.
That's actually what I initially thought target_gdbarch was
reporting. Full multi-arch is something that is also interesting
for multi-process. E.g, a bi-arch gdbserver, that supports
multi-process has issues, when trying to debug simultaneously
32-bit and 64-bit inferiors. In this case, we have one
target interface active (remote) and one target_gdbarch. Since
the register layouts in the protocol aren't dynamic depending
on the inferior (after the first inferior), on the multi-process
branch, gdbserver only allows debugging multiple inferiors if
they're of the same arch.
current_gdbarch of course bites back in this scenario as well.
BTW, what is the status of your per-frame gdbarch patches
submitted a while ago?
--
Pedro Alves