Re: current CVS gdb and SSE xmm registers don't work

Re: current CVS gdb and SSE xmm registers don't work

[Andrew Cagney]

> 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 :-/

	Andrew

Re: current CVS gdb and SSE xmm registers don't work

[Mark Kettenis]

Andrew Cagney <ac131313@cygnus.com> 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.

Mark

Re: current CVS gdb and SSE xmm registers don't work

[Felix Buenemann]

On Monday, 16. July 2001 15:00, you wrote:
> Andrew Cagney <ac131313@cygnus.com> 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 <ac131313@cygnus.com>
To: Nick Duffek <nsd@redhat.com>
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