This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]