This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: [PATCH] More updates to FXSR/SSE support in 2.4.0-test1
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