From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20355 invoked by alias); 30 Mar 2005 18:18:00 -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 20317 invoked from network); 30 Mar 2005 18:17:55 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 30 Mar 2005 18:17:55 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DGhmP-0007Xf-Rt; Wed, 30 Mar 2005 13:19:01 -0500 Date: Wed, 30 Mar 2005 18:18:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: m.m.kettenis@alumnus.utwente.nl, jon.ringle@comdial.com, gdb@sources.redhat.com Subject: Re: arm core analysis on x86 host Message-ID: <20050330181901.GA28934@nevyn.them.org> Mail-Followup-To: Mark Kettenis , m.m.kettenis@alumnus.utwente.nl, jon.ringle@comdial.com, gdb@sources.redhat.com References: <200503300928.36020.jon.ringle@comdial.com> <7320355463156182@weblx058.utsp.utwente.nl> <20050330152636.GA7867@nevyn.them.org> <200503301801.j2UI1uJC004771@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503301801.j2UI1uJC004771@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.6+20040907i X-SW-Source: 2005-03/txt/msg00304.txt.bz2 On Wed, Mar 30, 2005 at 08:01:56PM +0200, Mark Kettenis wrote: > 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. Well, yes. This is one of the reasons I added the default osabi mechanism. At least I think it was me :-) > 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. Right. APCS is simply the default for "unknown" ABIs; the sniffer is being over-eager. Patch forthcoming. > 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. I wonder if we should fall back to the executable's OSABI in some case? Anyway, not an urgent question. -- Daniel Jacobowitz CodeSourcery, LLC