From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: gareth@precisioninsight.com Cc: alan@lxorguk.ukuu.org.uk, drepper@redhat.com, adam@yggdrasil.com, linux-kernel@vger.rutgers.edu, bug-glibc@gnu.org, gdb@sourceware.cygnus.com Subject: Re: [PATCH] More updates to FXSR/SSE support in 2.4.0-test1 Date: Mon, 12 Jun 2000 13:59:00 -0000 Message-id: <200006122059.e5CKx9n30406@delius.kettenis.local> References: <394428DD.A2EFC21B@precisioninsight.com> <200006120002.e5C02mv14043@delius.kettenis.local> <39454E7B.593AFA66@precisioninsight.com> X-SW-Source: 2000-06/msg00094.html Date: Mon, 12 Jun 2000 14:56:27 -0600 From: Gareth Hughes > 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 */ #define NT_PRFPREG 2 /* prfpregset_t */ #define NT_PRPSINFO 3 /* prpsinfo_t */ #define NT_PRXREG 4 /* prxregset_t */ #define NT_PLATFORM 5 /* string from sysinfo(SI_PLATFORM) */ #define NT_AUXV 6 /* auxv_t array */ #define NT_GWINDOWS 7 /* gwindows_t SPARC only */ #define NT_ASRS 8 /* asrset_t SPARC V9 only */ #define NT_PSTATUS 10 /* pstatus_t */ #define NT_PSINFO 13 /* psinfo_t */ #define NT_PRCRED 14 /* prcred_t */ #define NT_UTSNAME 15 /* struct utsname */ #define NT_LWPSTATUS 16 /* lwpstatus_t */ #define NT_LWPSINFO 17 /* lwpsinfo_t */ 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 To: Fernando Nasser Cc: Andrew Cagney , GDB Discussion Subject: Re: That vision thing ... Date: Mon, 12 Jun 2000 15:00:00 -0000 Message-id: 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