Re: [PATCH] More updates to FXSR/SSE support in 2.4.0-test1

[Mark Kettenis <kettenis@wins.uva.nl>]

   Date: Mon, 12 Jun 2000 14:56:27 -0600
   From: Gareth Hughes <gareth@precisioninsight.com>

   > What exactly happens if you try to compile stock GDB 5.0 with the new
   > kernel?  Does it compile at all?  Is it seriously crippled?  Or does
   > it basically work right?

   It works (kind of), it's just extracting the FPU register data
   incorrectly and then misinterpreting the tag word and thus
   incorrectlying interpreting the incorrect data :-).  It's a pretty
   trivial patch, the extraction fix is contained in my last patch and I've
   just got to copy the tag word conversion code across.  Should have a
   patch in a couple of hours - busy with work at the moment.

Don't put too much effort into it.  I'm going to add some routines to
GDB that do the conversion from an FXSAVE area to GDB's internal
format that can be reused for other i386 targets besides Linux.

   > If there are major problems, it might be wise to choose a different
   > name for the PTRACE_{GET,SET}XFPREGS requests to avoid confusion.
   > That way, nobody will end up with a non-functional GDB (of course the
   > blame lies entirely with the GDB team for this mess).  My suggestion
   > would be to call those requests PTRACE_{GET,SET}FPXREGS.  It turns out
   > that Unixware uses a similar name for its FXSR support (they don't
   > have ptrace(), but they have a PCSFPXREG ioctl() and a __fpxregset_t
   > type[1]).  Moreover this makes the FSAVE/FPREGS vs. FXSAVE/FPXREGS
   > analogy a bit more explicit.

   I like this idea, makes a whole lot more sense.  This is kinda what I
   was arguing for way back in our previous emails.  It also matches up
   nicely with the signal handling types I've declared.  It would be good
   to get a working GDB 5.0 with a patch rather than a broken one when you
   haven't patched it.  The standard PTRACE_{GET|SET}FPREGS works fine as
   it stands, and in many cases this will be good enough.  When is the next
   release of GDB planned for?

I believe a new release cycle will be started in July, which should
lead to GDB 5.1 somewhere in November.

   I'd like some clarification on core dumping - will it be okay to add a
   new note NT_PRFPXREG, a new elf type elf_fpxregset_t and so on?  If so,
   I'll add this to the kernel and my GDB 5.0 patch and fire it off today.

Yep, that would be fine.  You'll have to choose a name for the note
too.  The other notes have the name "CORE", which is also used by
other SVR4-derived systems.  In that case you'd have to make sure that
NT_PRFPXREG doesn't clash with types that are already in use.  It's
probably better to choose a different name.  There are no rules but
the System V ABI suggests using the name of the vendor.  The old SSE
support uses "LINUX", which isn't such a bad idea (there is no reason
to choose a different name).  You can pick any number for NT_PRFPXREG,
but choosing one that's not already used in libbfd makes life a bit
easier.

Right now we have (see include/elf/common.h in the GDB/binutils
distribution):

#define NT_PRSTATUS	1		/* Contains copy of prstatus struct */
#define NT_FPREGSET	2		/* Contains copy of fpregset struct */
#define NT_PRPSINFO	3		/* Contains copy of prpsinfo struct */
#define NT_TASKSTRUCT	4		/* Contains copy of task struct */
#define NT_PRXFPREG     0x46e62b7f	/* Contains a user_xfpregs_struct; */
					/*   note name must be "LINUX".  */

/* Note segments for core files on dir-style procfs systems. */

#define NT_PSTATUS	10		/* Has a struct pstatus */
#define NT_FPREGS	12		/* Has a struct fpregset */
#define NT_PSINFO	13		/* Has a struct psinfo */
#define NT_LWPSTATUS	16		/* Has a struct lwpstatus_t */
#define NT_LWPSINFO	17		/* Has a struct lwpsinfo_t */
#define NT_WIN32PSTATUS	18		/* Has a struct win32_pstatus */


Where obviously NT_PRXFPREG will dissapear.


Solaris has (see /usr/include/sys/elf.h):

#define NT_PRSTATUS     1       /* prstatus_t   <sys/old_procfs.h>      */
#define NT_PRFPREG      2       /* prfpregset_t <sys/old_procfs.h>      */
#define NT_PRPSINFO     3       /* prpsinfo_t   <sys/old_procfs.h>      */
#define NT_PRXREG       4       /* prxregset_t  <sys/procfs.h>          */
#define NT_PLATFORM     5       /* string from sysinfo(SI_PLATFORM)     */
#define NT_AUXV         6       /* auxv_t array <sys/auxv.h>            */
#define NT_GWINDOWS     7       /* gwindows_t   SPARC only              */
#define NT_ASRS         8       /* asrset_t     SPARC V9 only           */
#define NT_PSTATUS      10      /* pstatus_t    <sys/procfs.h>          */
#define NT_PSINFO       13      /* psinfo_t     <sys/procfs.h>          */
#define NT_PRCRED       14      /* prcred_t     <sys/procfs.h>          */
#define NT_UTSNAME      15      /* struct utsname <sys/utsname.h>       */
#define NT_LWPSTATUS    16      /* lwpstatus_t  <sys/procfs.h>          */
#define NT_LWPSINFO     17      /* lwpsinfo_t   <sys/procfs.h>          */


Pick a number, and I'll make sure the necessary support will be added
to libbfd and GDB.

Mark
From qqi@world.std.com Mon Jun 12 15:00:00 2000
From: Quality Quorum <qqi@world.std.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: That vision thing ...
Date: Mon, 12 Jun 2000 15:00:00 -0000
Message-id: <Pine.SGI.3.95.1000612175947.11397A-100000@world.std.com>
References: <39450292.1B40EBB5@cygnus.com>
X-SW-Source: 2000-06/msg00095.html
Content-length: 962

On Mon, 12 Jun 2000, Fernando Nasser wrote:

> Quality Quorum wrote:
> > 
> > Can we split target depended pieces into subdirs under gdb ?
> > 
> 
> Aleksey,
> 
> For the majority of the targets we have only a single target dependent file.
> So most of these subdirectories will have a single file in it.  The exceptions
> would be few.
> 
> But a nice variant from your idea it would be a "targetdep" subdirectory for all
> these files.  This would reduce the large number of files under src/gdb and
> group together all that is related to different targets.  It still looks nice
> even with multi-arch I think.
> 
> We can continue on that line and group all those remote-* files as well...

It sounds nice.

> 
> -- 
> Fernando Nasser
> Red Hat Canada Ltd.                     E-Mail:  fnasser@cygnus.com
> 2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
> Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
> 

Thanks,

Aleksey