From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felix Buenemann (by way of Felix Buenemann ) To: Andrew Cagney Cc: gdb-patches@sourceware.cygnus.com Subject: Re: current CVS gdb and SSE xmm registers don't work Date: Mon, 16 Jul 2001 12:32:00 -0000 Message-id: <0107161723500E.13471@astral> X-SW-Source: 2001-07/msg00385.html On Monday, 16. July 2001 15:00, you wrote: > Andrew Cagney writes: > > > Hi, > > > > > > with current gdb+dejagnu (1day old) and also gdb from 20010622, > > > displaying of the Pentium IIIs SSE registers in gdb doesn't work > > > correct anymore, when I do for example print $xmm0 all 4 values > > > displayed are -NaN (always, even directly after loading data into that > > > register). > > > I'm using Linux 2.4.4 kernel with suse patches, compiled for PIII, gcc > > > 2.95.3 and glibc 2.2. Software I debugged was compiled with -g3 > > > compilerflag. > > > > > > > > > This is what it looks like: > > > (gdb) print $xmm0 > > > $12 = {f = {-nan(0x7fffff), -nan(0x7fffff), -nan(0x7fffff), > > > -nan(0x7fffff)}} > > > > > > I know that it worked with older snapshot from around april/may 2001, > > > but I've deleted that one :( > > > -- Best Regards, Felix > > > > What happens if you use gdb/i387-tdep.c version 1.9 instead of 1.12? > > Sounds like my ``tweek'' may still be breaking it :-/ > > I don't think your tweek has anything to do with it Andrew. From the > information Felix provides, I conclude that somehow a > PTRACE_GETFPXREGS request is failing (see > i386-linux-nat.c:fetch_fpxregs()). Therefore I would suspect this to > be a kernel bug, or misconfiguration. Felix, can debug GDB itself > (using GDB :-)) and see why that particular ptrace call is failing? I > cannot do this myself, since I don't have a PIII. hmm, ok I've recompiled gdb with debugging info, then did 'gdb gdb' ind gdb/ source dir and from (gdb-top) I set up breakpoint for i386-linux-nat.c:fetch_fpxregs then I issued run /root/develop/mplayer/main/mplayer to startup gdb to be debugged with program to be debugged and from (gdb) I did run [mplayers parameters]. So now from (gdb) I get nan as all four xmm dwords and from (top-gdb) it's 0 for all dwords (so it seems to work correct fro top-gdb). Now how shall I check if the fetch_fpxregs() funtion is disfunctioning? (sorry I'm not so familiar with debugging debuggers :) and mostly use gdb to dissassemble and check asm code) For now I've attached a backtrace from top-gdb, maybe it helps you. And thanks for the help! > Mark -- Best Regards, Felix >From ac131313@cygnus.com Mon Jul 16 13:37:00 2001 From: Andrew Cagney To: Nick Duffek Cc: jimb@cygnus.com, ezannoni@cygnus.com, gdb-patches@sources.redhat.com Subject: Re: [RFA] findvar.c: support LOC_BASEREG[_ARG] on Harvard archs Date: Mon, 16 Jul 2001 13:37:00 -0000 Message-id: <3B535097.5040106@cygnus.com> References: <200107161713.f6GHDNC08483@rtl.cygnus.com> X-SW-Source: 2001-07/msg00386.html Content-length: 1117 > Index: gdb/findvar.c > =================================================================== > diff -up gdb/findvar.c gdb/findvar.c> --- gdb/findvar.c Mon Jul 16 12:41:21 2001 > +++ gdb/findvar.c Mon Jul 16 12:39:40 2001 > @@ -612,9 +612,10 @@ addresses have not been bound by the dyn > case LOC_BASEREG_ARG: > { > char *buf = (char*) alloca (MAX_REGISTER_RAW_SIZE); > + memset (buf, 0, MAX_REGISTER_RAW_SIZE); > get_saved_register (buf, NULL, NULL, frame, SYMBOL_BASEREG (var), > NULL); > - addr = extract_address (buf, REGISTER_RAW_SIZE (SYMBOL_BASEREG (var))); > + addr = POINTER_TO_ADDRESS (builtin_type_void_data_ptr, buf); > addr += SYMBOL_VALUE (var); > break; FYI, I think this change will break the MIPS o64 ABI in big-endian mode. Under that ABI, 8 byte registers are used (and saved on the stack) but sizeof (void*) == 4. If I'm reading the above change correctly, pointer_to_address() will always extract the value from the first 4 bytes of of the register when, for o64/BE, it should be using the second 4 bytes. (The change is on the right track though). Andrew