This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: arm core analysis on x86 host
Date: Wed, 30 Mar 2005 10:26:36 -0500
From: Daniel Jacobowitz <drow@false.org>
On Wed, Mar 30, 2005 at 03:10:31PM +0000, M.M. Kettenis wrote:
> Secondly, the OS/ABI for core files don't have to match the executable
> exactly, but of course they have to be somewhat compatible. I know
> for sure that 32x64-bit cross debugging works on AMD64, and it is
> assumed to be working on PowerPC too. There might be some nasty
> side-effects though if you load a core file without the matching
> executable.
>
> However, if the OS/ABI's differ, be aware that
> regset_from_core_section() will be called for the OS/ABI of the core
> file. That regset_from_core_section() will have to do the proper
> translation on the register sets for the OS/ABI of the executable.
> That OS/ABI can be determined from the regcache that is passed to
> regset_from_core_section().
>
> I'd suggest looking at the i386/amd64 *BSD code or NetBSD/sparc64 code
> for good examples.
How does this work? In amd64_init_abi, we only call
set_gdbarch_regset_from_core_section if this OS/ABI has a registered
gregset. So if the core file is not tagged as Linux, then the right
OS/ABI's code will never be called.
The core file should somehow be tagged as Linux. If it is not tagged
as such, how are we going to interpret it? The fact that it is an ELF
core file, and has notes like NT_PRSTATUS does not tell us where each
register is stored. Right now we have to guess what the layout of
these notes is based on the size of the sections or because the header
describing the layout is available because we're building a native
GDB. But of course this all wrong [1].
A much better way to do things is the way NetBSD creates ELF core
file. They have their own set of notes, with a layout that is the
same on 32-bit and 64-bit architectures and names that clearly
proclaim this it's produced by NetBSD.
It looks to me from tracing this through on i386, that the reason
it works is because foo-*-linux* configurations default to
GDB_OSABI_LINUX and none of the OS/ABI sniffers trigger on the core
file. An accident, basically.
Not completely accidental. If we don't have the means to determine
the OS/ABI it makes sense to default to the target (implicitly)
selected by the user.
The reason this doesn't work for ARM is because the sniffer tags
the core file as GDB_OSABI_ARM_APCS. I've been meaning to change
the way ARM OS/ABI detection works, which will "fix" this as a side
effect; I will move that up my list and try to do it today.
Well, if there is some sort of standard ARM APCS core file this is
perfectly OK. In that case we shouldn't think about this as a Linux
core file, but an ARM APCS core file. There should be an ARM APCS
architecture vector with a regset_from_core_section() that knows how
to interpret it.
But i guess that's not the case.
But I'm left wondering about the overall design. How are we supposed
to figure out what sort of core file we have? Is the target
architecture required to arbitrate between possible subtarget core
formats? Do the sniffers need to become cleverer - if that's even
possible?
There are several possibilities. Yes, sniffers should be as clever as
they can possibly be. But the regset_from_core_section() functions
can be made cleverer too. And the core file reading code in BFD can
help too by generating core file sections with meaningful names.
Mark
[1] Unless of course we're really dealing with a standard SVR4 core
file here (which it really proclaims to be). However, we suffer
from the problem that we treat (generic) SVR4 ELF files as having
no OS/ABI.