Re: [0/2] Inspect extra signal information

[Pedro Alves <pedro@codesourcery.com>]

On Monday 12 January 2009 18:46:51, Pedro Alves wrote:
>  - Adds a new gdbarch method (get_siginfo_type) whose job is to return a type
>    suitable to print/inspect a TARGET_OBJECT_SIGNAL_INFO of a given arch.

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

The current patch assumed that PTRACE_GETSIGINFO would return
an object with the layout of the 32-bit inferior, but, we actually
get a 64-bit object.  In sum, the data/type returned by PTRACE_GETSIGINFO
is dependent on the arch of the *superior* (gdb).
The current patch was using the gdbarch of the current frame, but,
it is clear now that that is not the gdbarch we want.

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.

(now that I'm looking at it, can't an inferior that started
out as 32-bit call 64-bit code?  If so, it seems that gdbserver and 
target_gdbarch does not cope with that.)

The options I'm seeing are either:

 - come up with a new target/host *interface* gdbarch, and
   pass that along in the target description.  Use that gdbarch
   to build up the siginfo type, on the gdb side.

 - extend the xml type description support to be rich enough
   to describe the siginfo_t type (structs, typedefs, etc), and
   pass that along in the target description.

Any suggestions?  Other alternatives?

-- 
Pedro Alves