This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: 32-bit gcore on amd64
- From: Mark Kettenis <kettenis at chello dot nl>
- To: cagney at gnu dot org
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 20 Feb 2004 20:58:59 +0100 (CET)
- Subject: Re: 32-bit gcore on amd64
- References: <403542D6.2070603@gnu.org>
Date: Thu, 19 Feb 2004 18:12:22 -0500
From: Andrew Cagney <cagney@gnu.org>
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 :-).