This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: 32-bit gcore on amd64
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.
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