Re: 32-bit gcore on amd64

[Mark Kettenis <kettenis@chello.nl>]

   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 :-).