Re: [0/2] Inspect extra signal information

Pedro Alves
2009-02-03T15:02:01Z

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