From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32216 invoked by alias); 20 Feb 2004 19:59:11 -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 32209 invoked from network); 20 Feb 2004 19:59:09 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 20 Feb 2004 19:59:09 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i1KJx0t6000470; Fri, 20 Feb 2004 20:59:00 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i1KJwxL8000684; Fri, 20 Feb 2004 20:58:59 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id i1KJwxW4000681; Fri, 20 Feb 2004 20:58:59 +0100 (CET) Date: Fri, 20 Feb 2004 19:59:00 -0000 Message-Id: <200402201958.i1KJwxW4000681@elgar.kettenis.dyndns.org> From: Mark Kettenis To: cagney@gnu.org CC: gdb@sources.redhat.com In-reply-to: <403542D6.2070603@gnu.org> (message from Andrew Cagney on Thu, 19 Feb 2004 18:12:22 -0500) Subject: Re: 32-bit gcore on amd64 References: <403542D6.2070603@gnu.org> X-SW-Source: 2004-02/txt/msg00297.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. 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. #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. #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 :-).