Re: [0/2] Inspect extra signal information

[Pedro Alves <pedro@codesourcery.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