Re: [0/2] Inspect extra signal information

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Pedro Alves wrote:

> Boo, turns out that I had tested on x86-64:
> 
>  - 64-bit gdb x 64-bit inferior, 64-bit kernel
> 
>    siginfo comes out with the 64-bit layout.
> 
>  - 32-bit gdb x 32-bit inferior, 64-bit kernel
> 
>    siginfo comes out with the 32-bit layout.
> 
> 
> 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 ...

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 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).

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.

Bye,
Ulrich

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