From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24745 invoked by alias); 13 Oct 2003 13:44:33 -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 24729 invoked from network); 13 Oct 2003 13:44:31 -0000 Received: from unknown (HELO sadr.equallogic.com) (66.155.203.134) by sources.redhat.com with SMTP; 13 Oct 2003 13:44:31 -0000 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id h9DDiU4j027664 for ; Mon, 13 Oct 2003 09:44:30 -0400 Received: from deneb.dev.equallogic.com (deneb [172.16.1.99]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id h9DDiTZA027659; Mon, 13 Oct 2003 09:44:29 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id h9DDiRP06615; Mon, 13 Oct 2003 09:44:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16266.44095.175000.85307@gargle.gargle.HOWL> Date: Mon, 13 Oct 2003 13:44:00 -0000 From: Paul Koning To: drow@mvista.com Cc: kettenis@chello.nl, gdb@sources.redhat.com Subject: Re: [RFC] Core files and the architecture vector References: <200310112207.h9BM7WW0010332@elgar.kettenis.dyndns.org> <20031011222622.GB7209@nevyn.them.org> X-SW-Source: 2003-10/txt/msg00190.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: Daniel> I'll respond to the rest of your message later but... On Daniel> Sun, Oct 12, 2003 at 12:07:32AM +0200, Mark Kettenis wrote: >> Let me elaborate on the second point. When a 32-bit executable >> running on FreeBSD/amd64 or GNU/Linux x86-64 dumps, it produces an >> 64-bit ELF core file. To be able to make any sense out of this >> core file, we'll need the 64-bit register set definitions that are >> provided by the regset_from_core_section method from the 64-bit >> architecture Daniel> I still don't think this bit makes much sense. The process Daniel> sees only 32-bit registers; the core should contain only Daniel> 32-bit registers. Intuitively at least. On the other hand, Daniel> on MIPS64 (and x86-64?) a 32-bit process can actually access Daniel> 64-bit registers. It's forbidden to and the context Daniel> switching won't cope right, but it can be done anyway. Precisely for that reason the core file should contain the real registers, not the truncated ones. Taking a MIPS example: if supposedly 32-bit code somehow manages to have the upper 32 bits of the registers NOT be sign-extension as they are supposed to be, then Bad Things will happen to that program. If the core file only shows the truncated registers, you can't see what went wrong. paul