prgregset_t vs gdb_gregset_t on Linux: not the same!

prgregset_t vs gdb_gregset_t on Linux: not the same!

[Daniel Jacobowitz]

In proc-service.c, we call fill_gregset and supply_gregset with a
prgregset_t cast to a gdb_gregset_t *.  The problem is, they really are
different.  We can mostly get away with this, because in almost all cases
glibc won't do anything with the gregset except pass it back to gdb again
(if the process has terminated, it will memset something the size of a
prgregset_t, though...).

Now for the reason it's a problem: I don't have any idea where this
definition came from, but a prgregset_t on Linux/MIPS is smaller than an
elf_gregset_t by a considerable amount.  This caused me no end of confusion
while I was trying to add threads support to the MIPS port (which I've just
started feeding back patches for today).

Of course, the thread_db functions are defined to take a prgregset_t, so
it's unclear what we really can do.  Make sure we always allocate the size
of the larger one, perhaps, and assume glibc won't do too much damage?

The prgregset_t type unfortunately is one word too small for all the
registers we can get from ptrace(), even if I fill its pad words with data.

-- 
Daniel Jacobowitz                           Debian GNU/Linux Developer
Monta Vista Software                              Debian Security Team

Re: prgregset_t vs gdb_gregset_t on Linux: not the same!

[Daniel Jacobowitz]

On Fri, Jun 08, 2001 at 01:27:30PM -0700, Daniel Jacobowitz wrote:
> In proc-service.c, we call fill_gregset and supply_gregset with a
> prgregset_t cast to a gdb_gregset_t *.  The problem is, they really are
> different.  We can mostly get away with this, because in almost all cases
> glibc won't do anything with the gregset except pass it back to gdb again
> (if the process has terminated, it will memset something the size of a
> prgregset_t, though...).

The matching question here is that core-regset.c's fetch_core_registers
calls supply_gregset with a gregset_t, but supply_gregset is prototyped
with a gdb_gregset_t.  That doesn't work very well either.

-- 
Daniel Jacobowitz                           Debian GNU/Linux Developer
Monta Vista Software                              Debian Security Team

Re: prgregset_t vs gdb_gregset_t on Linux: not the same!

[H . J . Lu]

On Fri, Jun 08, 2001 at 03:59:07PM -0700, Daniel Jacobowitz wrote:
> On Fri, Jun 08, 2001 at 01:27:30PM -0700, Daniel Jacobowitz wrote:
> > In proc-service.c, we call fill_gregset and supply_gregset with a
> > prgregset_t cast to a gdb_gregset_t *.  The problem is, they really are
> > different.  We can mostly get away with this, because in almost all cases
> > glibc won't do anything with the gregset except pass it back to gdb again
> > (if the process has terminated, it will memset something the size of a
> > prgregset_t, though...).
> 
> The matching question here is that core-regset.c's fetch_core_registers
> calls supply_gregset with a gregset_t, but supply_gregset is prototyped
> with a gdb_gregset_t.  That doesn't work very well either.

I believe your Linux/MIPS patch is wrong. Please follow the examples in
linux/alpha, linux/i386 and linux/ppc. Basically, you have to include
config/tm-linux.h and config/nm-linux.h from the linux/mips header
files. But in order to do that, please make sure you do

#include <nm-linux.h>
#include <tm-linux.h>

not

#include "nm-linux.h"
#include "tm-linux.h"

Otherwise, you may not get the header files you want since mips has
both liltle and big endians. Once you have done that, your problem
should go away.



H.J.

Re: prgregset_t vs gdb_gregset_t on Linux: not the same!

[Mark Kettenis]

"H . J . Lu" <hjl@lucon.org> writes:

> I believe your Linux/MIPS patch is wrong. Please follow the examples in
> linux/alpha, linux/i386 and linux/ppc. Basically, you have to include
> config/tm-linux.h and config/nm-linux.h from the linux/mips header
> files. But in order to do that, please make sure you do
> 
> #include <nm-linux.h>
> #include <tm-linux.h>
> 
> not
> 
> #include "nm-linux.h"
> #include "tm-linux.h"
> 
> Otherwise, you may not get the header files you want since mips has
> both liltle and big endians. Once you have done that, your problem
> should go away.

Bullshit.

Mark

Re: prgregset_t vs gdb_gregset_t on Linux: not the same!

[Andrew Cagney]

> I believe your Linux/MIPS patch is wrong. Please follow the examples in
> linux/alpha, linux/i386 and linux/ppc. Basically, you have to include
> config/tm-linux.h and config/nm-linux.h from the linux/mips header
> files.


Most likely, yes.


> not
> 
> #include "nm-linux.h"
> #include "tm-linux.h"
> 
> Otherwise, you may not get the header files you want since mips has
> both liltle and big endians. Once you have done that, your problem
> should go away.


Just FYI, this isn't correct.

GDB configurations don't have -Isrc/gdb/config/$MACHINE added to the 
include path (if one does then it is broken).  Consequently "tm-linux.h" 
will find the header in src/gdb/config.

Besides, there are old farts that still believe that <> is reserved for 
system headers :-)

	Andrew

Re: prgregset_t vs gdb_gregset_t on Linux: not the same!

[H . J . Lu]

[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]

On Sat, Jun 09, 2001 at 12:05:02PM -0400, Andrew Cagney wrote:
> > 
> > #include "nm-linux.h"
> > #include "tm-linux.h"
> > 
> > Otherwise, you may not get the header files you want since mips has
> > both liltle and big endians. Once you have done that, your problem
> > should go away.
> 
> 
> Just FYI, this isn't correct.
> 
> GDB configurations don't have -Isrc/gdb/config/$MACHINE added to the 
> include path (if one does then it is broken).  Consequently "tm-linux.h" 
> will find the header in src/gdb/config.

Here is the ticky part. It took me a while to understand what is
going on. For mipsel, I have mips/tm-littlelinux.h in config, which
has

----
#ifndef TM_MIPSLITTLELINUX_H
#define TM_MIPSLITTLELINUX_H

#define TARGET_BYTE_ORDER LITTLE_ENDIAN

#include "mips/tm-linux.h"

#endif /* TM_MIPSLITTLELINUX_H */
----

The gdb configure links/copies mips/tm-littlelinux.h to tm.h. Now
gdb/tm.h has

---
#ifndef TM_MIPSLITTLELINUX_H
#define TM_MIPSLITTLELINUX_H

#define TARGET_BYTE_ORDER LITTLE_ENDIAN

#include "mips/tm-linux.h"
---

If in mips/tm-linux.h, there are

#include "mips/tm-mips.h"
#include "tm-linux.h"

mips/tm-linux.h is found by -Isrc/gdb/config. But can you guess which
tm-linux.h is included from mips/tm-linux.h? It is mips/tm-linux.h
since

#include "tm-linux.h"

for gcc, "" means to search the current directory of the file even if
it is not listed with -I. Therefor, tm-linux.h in config/mips will be
included from mips/tm-linux.h.  Here is an example

# make
gcc -M -I. foo.c
foo.o: foo.c tm.h mips/tm-linux.h
gcc -M -I. foo.c -DFIXED 
foo.o: foo.c tm.h mips/tm-linux.h tm-linux.h
 
Did I miss something here?


H.J.

[-- Attachment #2: cpp.tar.gz --]
[-- Type: application/x-gzip, Size: 421 bytes --]

Re: prgregset_t vs gdb_gregset_t on Linux: not the same!

[H . J . Lu]

On Sun, Jun 10, 2001 at 11:01:20AM +0300, Eli Zaretskii wrote:
> 
> On Sun, 10 Jun 2001, H . J . Lu wrote:
> 
> > The gdb configure links/copies mips/tm-littlelinux.h to tm.h. Now
> > gdb/tm.h has
> > 
> > ---
> > #ifndef TM_MIPSLITTLELINUX_H
> > #define TM_MIPSLITTLELINUX_H
> > 
> > #define TARGET_BYTE_ORDER LITTLE_ENDIAN
> > 
> > #include "mips/tm-linux.h"
> > ---
> > 
> > If in mips/tm-linux.h, there are
> > 
> > #include "mips/tm-mips.h"
> > #include "tm-linux.h"
> > 
> > mips/tm-linux.h is found by -Isrc/gdb/config. But can you guess which
> > tm-linux.h is included from mips/tm-linux.h? It is mips/tm-linux.h
> 
> This is all expected.  Perhaps it means that it's a bad idea to have 
> several headers by the same name in different directories, if some port 

It is a common practice in gcc and gdb.

> might include more than one of those headers, because small changes in 
> the order of the -I options can break the build.

It is ok to have files with the same name in src/gdb/config and
src/gdb/config/machine as long as

1. We never use -Isrc/gdb/config/machine. It has been true and I don't
think we should change.
2. We always use <> to include files in src/gdb/config/machine. That is
how it is done in gcc and I have sent a patch to do the same in gdb for
Linux:

http://sources.redhat.com/ml/gdb-patches/2001-05/msg00048.html


H.J.

Re: prgregset_t vs gdb_gregset_t on Linux: not the same!

[Andrew Cagney]

> # make
> gcc -M -I. foo.c
> foo.o: foo.c tm.h mips/tm-linux.h
> gcc -M -I. foo.c -DFIXED 
> foo.o: foo.c tm.h mips/tm-linux.h tm-linux.h
>  
> Did I miss something here?


Actually no. I'm wrong on this count.

Any way, back to the original tm-littlemips.h file:

> #ifndef TM_MIPSLITTLELINUX_H
> #define TM_MIPSLITTLELINUX_H
> 
> #define TARGET_BYTE_ORDER LITTLE_ENDIAN
> 
> #include "mips/tm-linux.h"


both the little and big endian GNU/Linux/MIPS targets should use a 
single config/mips/tm-linux.h file.  The code no longer needs to define 
TARGET_BYTE_ORDER.

With regard to #include "tm-linux.h", I'd mimic *bsd.  That way it is 
clear exactly what is going on.  Regardless of the semantics of "" vs <>.

	Andrew

Re: prgregset_t vs gdb_gregset_t on Linux: not the same!

[H . J . Lu]

On Mon, Jun 11, 2001 at 09:48:43AM -0400, Andrew Cagney wrote:
> 
> With regard to #include "tm-linux.h", I'd mimic *bsd.  That way it is 
> clear exactly what is going on.  Regardless of the semantics of "" vs <>.

I disagree. I prefer the gcc way. The gdb only gets away with "" is
we copy/link tm.h/xm.h/nm.h. If one day we ever want to have the gcc
style tm.h/xm.h/nm.h, where you have

# cat tm.h
#define TARGET_CPU_DEFAULT (MASK_GAS)
#ifdef IN_GCC
#include "gansidecl.h"
#endif
#ifdef IN_GCC
#include "elfos.h"
#endif
#ifdef IN_GCC
#include "mips/elfl.h"
#endif
#ifdef IN_GCC
#include "mips/linux.h"
#endif

"" won't work. I prefer <> over "".


H.J.

Re: prgregset_t vs gdb_gregset_t on Linux: not the same!

[Andrew Cagney]

> On Mon, Jun 11, 2001 at 09:48:43AM -0400, Andrew Cagney wrote:
> 
>> 
>> With regard to #include "tm-linux.h", I'd mimic *bsd.  That way it is 
>> clear exactly what is going on.  Regardless of the semantics of "" vs <>.
> 
> 
> I disagree. I prefer the gcc way. The gdb only gets away with "" is
> we copy/link tm.h/xm.h/nm.h. If one day we ever want to have the gcc
> style tm.h/xm.h/nm.h, where you have


You've lost me here.  How can #include "config/tm-nbsd.h" not work?

BTW, it wouldn't make sense for GDB to adopt GCC's tm/xm/nm arangement 
since that doesn't facilitate multi-arch.  See the TODO file.

	enjoy,
		Andrew

Re: prgregset_t vs gdb_gregset_t on Linux: not the same!

[Daniel Jacobowitz]

On Mon, Jun 11, 2001 at 09:48:43AM -0400, Andrew Cagney wrote:
> > #ifndef TM_MIPSLITTLELINUX_H
> > #define TM_MIPSLITTLELINUX_H
> > 
> > #define TARGET_BYTE_ORDER LITTLE_ENDIAN
> > 
> > #include "mips/tm-linux.h"
> 
> 
> both the little and big endian GNU/Linux/MIPS targets should use a 
> single config/mips/tm-linux.h file.  The code no longer needs to define 
> TARGET_BYTE_ORDER.

Thanks, so I see.

> With regard to #include "tm-linux.h", I'd mimic *bsd.  That way it is 
> clear exactly what is going on.  Regardless of the semantics of "" vs <>.

Mimic *bsd in what?  In GDB, the only BSD headers I see under config/
are *-nbsd.h, and those have the same problem we do...

-- 
Daniel Jacobowitz                           Debian GNU/Linux Developer
Monta Vista Software                              Debian Security Team

Re: prgregset_t vs gdb_gregset_t on Linux: not the same!

[H . J . Lu]

On Mon, Jun 11, 2001 at 09:24:12AM -0700, Daniel Jacobowitz wrote:
> > With regard to #include "tm-linux.h", I'd mimic *bsd.  That way it is 
> > clear exactly what is going on.  Regardless of the semantics of "" vs <>.
> 
> Mimic *bsd in what?  In GDB, the only BSD headers I see under config/
> are *-nbsd.h, and those have the same problem we do...
> 

IMHO, minic any *bsd config for Linux/mips is asking for trouble.
Linux/mips should minic a working, similar Linux config. I will take
a look at alpha, ia64, ppc, x86, in that order. Of course, it is always
a good idea to use <>, not "" to include xx-linux.h.


H.J.

Re: prgregset_t vs gdb_gregset_t on Linux: not the same!

[Daniel Jacobowitz]

On Mon, Jun 11, 2001 at 09:45:26AM -0700, H . J . Lu wrote:
> On Mon, Jun 11, 2001 at 09:24:12AM -0700, Daniel Jacobowitz wrote:
> > > With regard to #include "tm-linux.h", I'd mimic *bsd.  That way it is 
> > > clear exactly what is going on.  Regardless of the semantics of "" vs <>.
> > 
> > Mimic *bsd in what?  In GDB, the only BSD headers I see under config/
> > are *-nbsd.h, and those have the same problem we do...
> > 
> 
> IMHO, minic any *bsd config for Linux/mips is asking for trouble.
> Linux/mips should minic a working, similar Linux config. I will take
> a look at alpha, ia64, ppc, x86, in that order. Of course, it is always
> a good idea to use <>, not "" to include xx-linux.h.

You don't need to do that.  I'll be posting a complete, functional MIPS
port as soon as the preliminary patches I posted last week are
addressed.

-- 
Daniel Jacobowitz                           Debian GNU/Linux Developer
Monta Vista Software                              Debian Security Team

Re: prgregset_t vs gdb_gregset_t on Linux: not the same!

[H . J . Lu]

On Mon, Jun 11, 2001 at 10:05:07AM -0700, Daniel Jacobowitz wrote:
> > IMHO, minic any *bsd config for Linux/mips is asking for trouble.
> > Linux/mips should minic a working, similar Linux config. I will take
> > a look at alpha, ia64, ppc, x86, in that order. Of course, it is always
> > a good idea to use <>, not "" to include xx-linux.h.
> 
> You don't need to do that.  I'll be posting a complete, functional MIPS

By "I", I meant if I would do it myself.

> port as soon as the preliminary patches I posted last week are
> addressed.

Thanks. I am looking forward to it.


H.J.

Re: prgregset_t vs gdb_gregset_t on Linux: not the same!

[Daniel Jacobowitz]

On Fri, Jun 08, 2001 at 10:14:52PM -0700, H . J . Lu wrote:
> On Fri, Jun 08, 2001 at 03:59:07PM -0700, Daniel Jacobowitz wrote:
> > On Fri, Jun 08, 2001 at 01:27:30PM -0700, Daniel Jacobowitz wrote:
> > > In proc-service.c, we call fill_gregset and supply_gregset with a
> > > prgregset_t cast to a gdb_gregset_t *.  The problem is, they really are
> > > different.  We can mostly get away with this, because in almost all cases
> > > glibc won't do anything with the gregset except pass it back to gdb again
> > > (if the process has terminated, it will memset something the size of a
> > > prgregset_t, though...).
> > 
> > The matching question here is that core-regset.c's fetch_core_registers
> > calls supply_gregset with a gregset_t, but supply_gregset is prototyped
> > with a gdb_gregset_t.  That doesn't work very well either.
> 
> I believe your Linux/MIPS patch is wrong. Please follow the examples in
> linux/alpha, linux/i386 and linux/ppc. Basically, you have to include
> config/tm-linux.h and config/nm-linux.h from the linux/mips header
> files. But in order to do that, please make sure you do

Huh?  Did you even read what I wrote? gdb_gregset_t and
gregset_t/prgregset_t are NOT THE SAME SIZE.

config/nm-linux.h has:
/* Use elf_gregset_t and elf_fpregset_t, rather than
   gregset_t and fpregset_t.  */

#define GDB_GREGSET_T  elf_gregset_t
#define GDB_FPREGSET_T elf_fpregset_t

So gdb_gregset_t is elg_gregset_t.  which, the kernel defines as
an array of 45 elf_greg_t's in <asm/elf.h>.

But prgregset_t is gregset_t
(from <sys/procfs.h>:
 /* Register sets.  Linux has different names.  */
 typedef gregset_t prgregset_t;
 typedef fpregset_t prfpregset_t;
)

And gregset_t is (<sys/ucontext.h>):
#define NGREG   37
#define NFPREG  33

/* Container for all general registers.  */
/* gregset_t must be an array.  The below declared array corresponds
to:
typedef struct gregset {
        greg_t  g_regs[32];
        greg_t  g_hi;
        greg_t  g_lo;
        greg_t  g_pad[3];
} gregset_t;  */
typedef greg_t gregset_t[NGREG];




> 
> #include <nm-linux.h>
> #include <tm-linux.h>
> 
> not
> 
> #include "nm-linux.h"
> #include "tm-linux.h"
> 
> Otherwise, you may not get the header files you want since mips has
> both liltle and big endians. Once you have done that, your problem
> should go away.

The little endian config files are not named xm-linux.h and tm-linux.h
in a separate directory.  They're named xm-littlelinux.h and
tm-littlelinux.h.

-- 
Daniel Jacobowitz                           Debian GNU/Linux Developer
Monta Vista Software                              Debian Security Team

Re: prgregset_t vs gdb_gregset_t on Linux: not the same!

[Mark Kettenis]

Daniel Jacobowitz <dmj+@andrew.cmu.edu> writes:

> On Fri, Jun 08, 2001 at 01:27:30PM -0700, Daniel Jacobowitz wrote:
> > In proc-service.c, we call fill_gregset and supply_gregset with a
> > prgregset_t cast to a gdb_gregset_t *.  The problem is, they really are
> > different.  We can mostly get away with this, because in almost all cases
> > glibc won't do anything with the gregset except pass it back to gdb again
> > (if the process has terminated, it will memset something the size of a
> > prgregset_t, though...).
> 
> The matching question here is that core-regset.c's fetch_core_registers
> calls supply_gregset with a gregset_t, but supply_gregset is prototyped
> with a gdb_gregset_t.  That doesn't work very well either.

It's a mess.  Linux should have three different regset types:

 * elf_gregset_t: The type used for register sets in ELF core dumps.
   Should be defined by <sys/procfs.h>.

 * prgregset_t: The type used for register sets in the
   <proc_service.h> debugging interface.

 * gregset_t: The type used for register sets in machine contexts.
   Should be defined in <sys/ucontext.h>.

On many Linux ports the elf_gregset_t and gregset_t types differ, and
apparently the MIPS port is one of them.  The type prgregset_t is
equivalent to one of them, but which one?  To make matters worse
<linux/elfcore.h> has a

   typedef elf_gregset_t gregset_t;

which means that there might be two different types bearing the same
name.  Which type you get depends on what headers you include.

The first thing you'll need to do is cleanup up the glibc headers for
MIPS.  The important headers are <sys/procfs.h>, <sys/ucontext.h> and
<sys/user.h>.  Avoid including Linux kernel headers and copy the few
definitions that you really need.  Avoid cross-includes.  I cleaned up
the i386 headers some time ago.  Take a look at those to see what I
mean.

Then for GDB you need to make sure that gdb_gregset_t is equivalent to
elf_gregset_t.  The file config/nm-linux.h makes sure it is by
defining GDB_GREGSET_T.  You should include this file from
config/mips/nm-linux (or whatever your native configuration header is
called).

The proc-service.c module assumes that gdb_gregset_t and prgregset_t
are equivalent types.  Preferably, you should fix glibc such that that
is the case.  You might need to change the version of the
libthread_db.so library if you're worried about backward compatibility.

We could add conversion routines for prgregset_t in GDB, but I'd like
to avoid that.

Mark

Re: prgregset_t vs gdb_gregset_t on Linux: not the same!

[Daniel Jacobowitz]

On Sat, Jun 09, 2001 at 09:01:49PM +0200, Mark Kettenis wrote:
> Daniel Jacobowitz <dmj+@andrew.cmu.edu> writes:
> 
> > On Fri, Jun 08, 2001 at 01:27:30PM -0700, Daniel Jacobowitz wrote:
> > > In proc-service.c, we call fill_gregset and supply_gregset with a
> > > prgregset_t cast to a gdb_gregset_t *.  The problem is, they really are
> > > different.  We can mostly get away with this, because in almost all cases
> > > glibc won't do anything with the gregset except pass it back to gdb again
> > > (if the process has terminated, it will memset something the size of a
> > > prgregset_t, though...).
> > 
> > The matching question here is that core-regset.c's fetch_core_registers
> > calls supply_gregset with a gregset_t, but supply_gregset is prototyped
> > with a gdb_gregset_t.  That doesn't work very well either.
> 
> It's a mess.  Linux should have three different regset types:
> 
>  * elf_gregset_t: The type used for register sets in ELF core dumps.
>    Should be defined by <sys/procfs.h>.
> 
>  * prgregset_t: The type used for register sets in the
>    <proc_service.h> debugging interface.
> 
>  * gregset_t: The type used for register sets in machine contexts.
>    Should be defined in <sys/ucontext.h>.
> 
> On many Linux ports the elf_gregset_t and gregset_t types differ, and
> apparently the MIPS port is one of them.  The type prgregset_t is
> equivalent to one of them, but which one?  To make matters worse
> <linux/elfcore.h> has a
> 
>    typedef elf_gregset_t gregset_t;
> 
> which means that there might be two different types bearing the same
> name.  Which type you get depends on what headers you include.

Right.  Nothing in GDB that I can find and nothing in sys/, bits/, or
straight usr/include/ gets <linux/elfcore.h>, fortunately.

> The first thing you'll need to do is cleanup up the glibc headers for
> MIPS.  The important headers are <sys/procfs.h>, <sys/ucontext.h> and
> <sys/user.h>.  Avoid including Linux kernel headers and copy the few
> definitions that you really need.  Avoid cross-includes.  I cleaned up
> the i386 headers some time ago.  Take a look at those to see what I
> mean.

The only two kernel headers we get right now in the relevant portions
are <asm/elf.h> and <asm/user.h>; asm/elf.h gives us the reasonable
definition of elf_gregset_t, and asm/user.h gives us struct user, which
gives us the offsets into an elf_gregset_t for particular registers.

> Then for GDB you need to make sure that gdb_gregset_t is equivalent to
> elf_gregset_t.  The file config/nm-linux.h makes sure it is by
> defining GDB_GREGSET_T.  You should include this file from
> config/mips/nm-linux (or whatever your native configuration header is
> called).

Yep, already got that.

> The proc-service.c module assumes that gdb_gregset_t and prgregset_t
> are equivalent types.  Preferably, you should fix glibc such that that
> is the case.  You might need to change the version of the
> libthread_db.so library if you're worried about backward compatibility.

Do you think I could get away with this?  I can't (as much as I'm
tempted) change the actual gregset_t, since it is used in things like
ucontext_t.  But since nothing uses a prgregset_t outside of thread_db,
that might be possible.

libc people?  Is something like this reasonable for
sysdeps/unix/sysv/linux/mips/sys/procfs.h, possibly with a libthread_db
version bump (although since I doubt anything successfully uses
thread_db on mips yet...):

- typedef gregset_t prgregset_t;
- typedef fpregset_t prfpregset_t;
+ typedef elf_gregset_t prgregset_t;
+ typedef elf_fpregset_t prfpregset_t;

I notice that a lot of platforms have these two as separate types.

prgregset_t is elf_gregset_t: i386, hppa, s390, sparc
prgregset_t is gregset_t: powerpc, alpha, mips, ia64, and all others
	(linux/sys/procfs.h - I guess that's m68k and sh)

Since we only use prgregset_t for thread_db, I think elf_gregset_t is
more appropriate.  I don't entirely understand why gregset_t and
elf_gregset_t are different, though.  What we really want to return
is what we get from ptrace, which seems to be closer to elf_gregset_t
on most platforms.


> We could add conversion routines for prgregset_t in GDB, but I'd like
> to avoid that.

I'm not sure we could, though - a prgegset_t is too small to hold what
we want to put in a gdb_gregset_t!

-- 
Daniel Jacobowitz                           Debian GNU/Linux Developer
Monta Vista Software                              Debian Security Team