From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19386 invoked by alias); 13 Dec 2004 20:02:22 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 19344 invoked from network); 13 Dec 2004 20:02:15 -0000 Received: from unknown (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 13 Dec 2004 20:02:15 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id iBDK22Kw004248; Mon, 13 Dec 2004 21:02:03 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id iBDK22mS001110; Mon, 13 Dec 2004 21:02:02 +0100 (CET) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id iBDK22Uc001107; Mon, 13 Dec 2004 21:02:02 +0100 (CET) Date: Mon, 13 Dec 2004 20:22:00 -0000 Message-Id: <200412132002.iBDK22Uc001107@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: orjan.friberg@axis.com CC: gdb-patches@sources.redhat.com, hans-peter.nilsson@axis.com In-reply-to: <41BDAA01.6080101@axis.com> (message from Orjan Friberg on Mon, 13 Dec 2004 15:41:05 +0100) Subject: Re: [CRIS] Reading core file selects "wrong" mach References: <41ADCE5B.5010001@axis.com> <200412021718.iB2HIK1Q004810@elgar.sibelius.xs4all.nl> <41BDAA01.6080101@axis.com> X-SW-Source: 2004-12/txt/msg00363.txt.bz2 Date: Mon, 13 Dec 2004 15:41:05 +0100 From: Orjan Friberg > Is there an implicit assumption that the mach is not to be trusted > when reading a core file? > > What do you mean by "not to be trusted"? It's simply always set to > the default machine for ELF core files. For most architectures this > is what makes the most sense anyway. Setting it to anything different > from the default would involve some architecture-dependent code. I What I meant was that I couldn't find any other port that looked at the mach in their grok_prstatus/grok_prinfo, which led me to think there might be a reason they didn't. Well, needlessly setting the machine could cause problems, and we shouldn't blindly do that. But I think it's safe to say that it's just because it didn't matter. GDB didn't really pay attention to the architecture of the core file until rather recently. > guess the correct way to do this would be adding > elf_set_mach_from_flags() to `struct elf_backend_data', and use that > in elf_core_file_p() to set the machine after the architecture has > been set. Yes, that makes sense. Thanks. I guess the answer to this is 'no', but would it be possible (and correct) to use whatever machine was set when loading the corresponding program into GDB? No. (See you got it right.) The machine in the core file doesn't necessarily match the machine for the loaded executable. This mainly arises in 32-bit x 64-bit cross-debugging. Some 64-bit operating systems will generate 64-bit core files, even when running 32-bit code. GDB uses the machine type to recognize the layout of the core file in such a situation. Example are sparc/sparcv9 or i386/x86_64. Mark