Re: 32-bit gcore on amd64

[Andrew Cagney <cagney@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.

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