From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14621 invoked by alias); 20 Feb 2004 21:06:58 -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 14551 invoked from network); 20 Feb 2004 21:06:54 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 20 Feb 2004 21:06:54 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id A70B92B92; Fri, 20 Feb 2004 16:06:51 -0500 (EST) Message-ID: <403676EB.2070803@gnu.org> Date: Fri, 20 Feb 2004 21:06:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Mark Kettenis Cc: gdb@sources.redhat.com Subject: Re: 32-bit gcore on amd64 References: <403542D6.2070603@gnu.org> <200402201958.i1KJwxW4000681@elgar.kettenis.dyndns.org> In-Reply-To: <200402201958.i1KJwxW4000681@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00299.txt.bz2 > Date: Thu, 19 Feb 2004 18:12:22 -0500 > From: Andrew Cagney > > This is more questions than answers. I'm trying to figure out how GDB > should generate 32-bit core files on amd64 (i.e., get gmake check > 'RUNTESTFLAGS=--target_board=unix/-m32 gcore.exp' to pass). The problem > is, everything I look at feels wrong. > > OK. First we have to determine what gcore should generate. Most > UNIX-like kernels will produce a native core dump, even if they're > "emulating" another system; x86_64 Linux will produce a 64-bit core > dump when running a 32-bit binary, FreeBSD/i386 will produce a FreeBSD > core dump when running a Linux binary. Do we want gcore to do the same? > > I don't think so, and you seem to think the same. But some people > might have a different optinion. Yes. I think they wimped out :-), and yes, I've seen different opinions. If an emulation layer is true to itself, it won't be possible for anything running within that layer to determine that things are being emulated. For instance this: $ file bigcore 32-bit i386 $ ./bigcore Segmentation fault, core dumped $ file bigcore.corefile 64-bit core file fails the 32-bit emulation layer turing test. BTW, on my amd64 the linux kernel "works": $ file bigcore bigcore: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped $ ./bigcore .... Segmentation fault (core dumped) $ file core.25607 core.25607: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style, from 'bigcore' $ If GDB doesn't follow this, we're going to end up with some pretty weird stuff. For instance: amd64-elf-gdb i386.exe (gdb) target remote ... (gdb) gcore "clearly" needs to generate an i386 core file. > Here's the first backtrace: > > #0 amd64_collect_native_gregset (regcache=0x808410, gregs=0x7fbfffead0, > regnum=-1) at /home/cygnus/cagney/GDB/src/gdb/amd64-nat.c:124 > #1 0x0000000000450e16 in fill_gregset (gregsetp=0x808410, > regnum=-1073747248) > at /home/cygnus/cagney/GDB/src/gdb/x86-64-linux-nat.c:126 > #2 0x000000000045803d in linux_do_thread_registers (obfd=0x87fc90, ptid= > {pid = 10494, lwp = 10494, tid = 0}, note_data=0x8b0960 "\005", > note_size=0x7fbfffed8c) at > /home/cygnus/cagney/GDB/src/gdb/linux-proc.c:180 > > This function is asking fill_gregset to populate an amd64 gregset_t. I > think it should be asking for the 32-bit gregset_t to be filled in. > > We should get rid of fill_gregset. I still intend to extend the > register set support such that it can be used for this purpose. Yes, I remember that now. > #3 0x0000000000458227 in linux_do_registers (obfd=0x87fc90, ptid= > {pid = 10494, lwp = 0, tid = 0}, note_data=0x8b0960 "\005", > note_size=0x7fbfffed8c) at > /home/cygnus/cagney/GDB/src/gdb/linux-proc.c:250 > #4 0x00000000004583f8 in linux_make_note_section (obfd=0x87fc90, > note_size=0x7fbfffed8c) at > /home/cygnus/cagney/GDB/src/gdb/linux-proc.c:302 > > Here, I'm thinking that if this is to be portable, this would have to be > an architecture method (also parameterized with the target). > > The layout of a core file, especially the notes that will be emitted, > is defenitely related to the OS ABI. So yes, we need an architecture > method. > > #5 0x00000000004594d2 in gcore_command (args=0x0, from_tty=-1073747248) > at /home/cygnus/cagney/GDB/src/gdb/gcore.c:80 > > Now the second backtrace: > > #0 elfcore_write_prstatus (abfd=0x87fc90, buf=0x8b0960 "\005", > bufsiz=0x7fbfffed8c, pid=10494, cursig=5, gregs=0x7fbfffead0) > at /home/cygnus/cagney/GDB/src/bfd/elf.c:7163 > > This function totally assumes that it's creating a 64-bit note section. > How does BFD figure out that it should instead use 32-bit note code? > > Well, it can determine the target from ABFD. It certainly can make > the distinction between a 32-bit and a 64-bit BFD. However, some > targets, most notably ELF, are shared by various OSes. So in theory. Wonder if this is something better handled directly by GDB - who, other than gdb wants to create corefiles? > #1 0x0000000000458058 in linux_do_thread_registers (obfd=0x87fc90, ptid= > {pid = 10494, lwp = 10494, tid = 0}, note_data=0x8b0960 "\005", > note_size=0x7fbfffed8c) at > /home/cygnus/cagney/GDB/src/gdb/linux-proc.c:181 > #2 0x0000000000458227 in linux_do_registers (obfd=0x87fc90, ptid= > {pid = 10494, lwp = 0, tid = 0}, note_data=0x8b0960 "\005", > note_size=0x7fbfffed8c) at > /home/cygnus/cagney/GDB/src/gdb/linux-proc.c:250 > #3 0x00000000004583f8 in linux_make_note_section (obfd=0x87fc90, > note_size=0x7fbfffed8c) at > /home/cygnus/cagney/GDB/src/gdb/linux-proc.c:302 > #4 0x00000000004594d2 in gcore_command (args=0x0, from_tty=-1073747032) > at /home/cygnus/cagney/GDB/src/gdb/gcore.c:80 > > Andrew > > As a somewhat amazing PS: bigcore.exp does pass 32-bit mode on AMD-64 > ->> the 32-bit read path is ok. > > I tried to make that work :-). wicked. Andrew