From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32397 invoked by alias); 30 Mar 2005 18:02:18 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 32323 invoked from network); 30 Mar 2005 18:02:09 -0000 Received: from unknown (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 30 Mar 2005 18:02:09 -0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id j2UI1vnv014452; Wed, 30 Mar 2005 20:01:57 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.3/8.13.3) with ESMTP id j2UI1u8m026828; Wed, 30 Mar 2005 20:01:56 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.3/8.13.3/Submit) id j2UI1uJC004771; Wed, 30 Mar 2005 20:01:56 +0200 (CEST) Date: Wed, 30 Mar 2005 18:02:00 -0000 Message-Id: <200503301801.j2UI1uJC004771@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: m.m.kettenis@alumnus.utwente.nl, jon.ringle@comdial.com, gdb@sources.redhat.com In-reply-to: <20050330152636.GA7867@nevyn.them.org> (message from Daniel Jacobowitz on Wed, 30 Mar 2005 10:26:36 -0500) Subject: Re: arm core analysis on x86 host References: <200503300928.36020.jon.ringle@comdial.com> <7320355463156182@weblx058.utsp.utwente.nl> <20050330152636.GA7867@nevyn.them.org> X-SW-Source: 2005-03/txt/msg00303.txt.bz2 Date: Wed, 30 Mar 2005 10:26:36 -0500 From: Daniel Jacobowitz 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.