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
- Date: Tue, 3 Feb 2009 15:01:49 +0000
- Subject: Re: [0/2] Inspect extra signal information
- References: <200901121846.51709.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