Re: 32-bit gcore on amd64

Re: 32-bit gcore on amd64

[Ulrich Weigand]

Andrew Cagney wrote:

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

Yup, same problem on s390x.  In fact, the gcore tests are the only
failing tests when running the s390-on-s390x bi-arch test suite
(in addition to those that fail on native s390, of course).

[snip elfcore_write_prstatus]
>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?

It doesn't, as far as I can see.

>As a somewhat amazing PS: bigcore.exp does pass 32-bit mode on 
>AMD-64 ->> the 32-bit read path is ok.

That's because there are tons of special-cased code pieces in
the *read* path to handle this; check for HAVE_PRPSINFO32_T
and HAVE_PRSTATUS32_T in bfd/elf.c.  (This relies on sys/procfs.h
to provide both 32-bit and 64-bit versions -- reading cores
didn't work initially on s390x because those were missing.)

Such special cases are completely absent from the write path,
however.

(The other question is whether these 32-on-64 special cases are
really the right way to solve the problem -- a generic solution
should preferably solve the any-on-any cross-gdb core dump 
access problem ...)
 
Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: 32-bit gcore on amd64

[Andrew Cagney]

>>>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?
> 
> 
> It doesn't, as far as I can see.

Ah, "good", at least I wasn't missing anything.

>>>As a somewhat amazing PS: bigcore.exp does pass 32-bit mode on 
>>>AMD-64 ->> the 32-bit read path is ok.
> 
> 
> That's because there are tons of special-cased code pieces in
> the *read* path to handle this; check for HAVE_PRPSINFO32_T
> and HAVE_PRSTATUS32_T in bfd/elf.c.  (This relies on sys/procfs.h
> to provide both 32-bit and 64-bit versions -- reading cores
> didn't work initially on s390x because those were missing.)
> 
> Such special cases are completely absent from the write path,
> however.
> 
> (The other question is whether these 32-on-64 special cases are
> really the right way to solve the problem -- a generic solution
> should preferably solve the any-on-any cross-gdb core dump 
> access problem ...)

That's why I'm thinking that:

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

belongs in the architecture vector.

Andrew

32-bit gcore on amd64

[Andrew Cagney]

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.

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.

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

#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?

#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.

Re: 32-bit gcore on amd64

[Daniel Jacobowitz]

On Thu, Feb 19, 2004 at 06:12:22PM -0500, Andrew Cagney wrote:
> 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.
> 
> 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.

Does the same thing apply to mips64-linux/-mabi=32?  Normally we make a
point of only dealing with the registers' "real" size.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: 32-bit gcore on amd64

[Andrew Cagney]

> On Thu, Feb 19, 2004 at 06:12:22PM -0500, Andrew Cagney wrote:
> 
>>> 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.
>>> 
>>> 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.
> 
> 
> Does the same thing apply to mips64-linux/-mabi=32?  Normally we make a
> point of only dealing with the registers' "real" size.

"Possibly", can you clarify this a little?

GDB debugging a 32-bit i386 program should always "gcore" a 32-bit i386 
core file.

Andrew

Re: 32-bit gcore on amd64

[Daniel Jacobowitz]

On Thu, Feb 19, 2004 at 07:17:03PM -0500, Andrew Cagney wrote:
> >On Thu, Feb 19, 2004 at 06:12:22PM -0500, Andrew Cagney wrote:
> >
> >>>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.
> >>>
> >>>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.
> >
> >
> >Does the same thing apply to mips64-linux/-mabi=32?  Normally we make a
> >point of only dealing with the registers' "real" size.
> 
> "Possibly", can you clarify this a little?
> 
> GDB debugging a 32-bit i386 program should always "gcore" a 32-bit i386 
> core file.

I was just referring to the same thing Mark mentioned: what the kernel
actually dumps.  I'm pretty sure a MIPS64 Linux kernel dumps 64-bit
core files for all programs.  On the other hand, it looks like the
latest 2.6 kernels don't do that any more; how fast I am outdated...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: 32-bit gcore on amd64

[Mark Kettenis]

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

Re: 32-bit gcore on amd64

[Andrew Cagney]

>    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

Re: 32-bit gcore on amd64

[Mark Kettenis]

   Date: Fri, 20 Feb 2004 16:06:51 -0500
   From: Andrew Cagney <cagney@gnu.org>

   > 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?

Why shouldn't objdump be able to write a core file?

;-)

But seriously, yes I think we should let GDB handle the gory details.
BFD should only provide the basic, generic functionality.  For ELF
this means we'd keep the generic functionality to write core file
notes (i.e. elfcore_write_note()) in BFD, but move the functions that
create the OS-specific data structure inside those notes
(i.e. elfcore_write_prpsinfo() and elfcore_write_prstatus()) into GDB.

Mark