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

[Felix Buenemann <atmosfear at users dot sf dot net> (by way of Felix Buenemann <atmosfear at users dot sf dot net>)]

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
(top-gdb) cont
Continuing.
cont
Continuing.
A:  25.3 (  25.3)  V:  25.3  A-V: -0.019 ct:  0.058  508  3771%  0%  1.7% 28
Breakpoint 4, fetch_fpxregs (tid=31631) at i386-linux-nat.c:472
472       if (! have_ptrace_getfpxregs)
(top-gdb) bt
#0  fetch_fpxregs (tid=31631) at i386-linux-nat.c:472
#1  0x080ab051 in fetch_inferior_registers (regno=-1) at i386-linux-nat.c:621
#2  0x080adbf0 in lin_lwp_fetch_registers (regno=-1) at lin-lwp.c:1254
#3  0x080eefbf in thread_db_fetch_registers (regno=-1) at thread-db.c:782
#4  0x080edd1f in ps_lgetregs (ph=0x82059a0, lwpid=31631, gregset=0xbfffee4c) at proc-service.c:235
#5  0x401afe9e in td_thr_getgregs () from /lib/libthread_db.so.1
#6  0x080ef045 in thread_db_fetch_registers (regno=8) at thread-db.c:791
#7  0x080e6f05 in fetch_register (regnum=8) at regcache.c:124
#8  0x080e7190 in legacy_read_register_gen (regnum=8, myaddr=0xbfffef38 "ð\017") at regcache.c:289
#9  0x080e723d in read_register_gen (regnum=8, buf=0xbfffef38 "ð\017") at regcache.c:308
#10 0x080e752e in read_register (regnum=8) at regcache.c:432
#11 0x080e75df in read_register_pid (regnum=8, ptid={pid = 31631, lwp = 0, tid = 1024})
    at regcache.c:444
#12 0x080e78ac in generic_target_read_pc (ptid={pid = 31631, lwp = 0, tid = 1024}) at regcache.c:593
#13 0x080e7900 in read_pc_pid (ptid={pid = 31631, lwp = 0, tid = 1024}) at regcache.c:612
#14 0x080936af in handle_inferior_event (ecs=0xbffff0bc) at infrun.c:1852
#15 0x08092a7b in wait_for_inferior () at infrun.c:1263
#16 0x08092861 in proceed (addr=4294967295, siggnal=TARGET_SIGNAL_DEFAULT, step=0) at infrun.c:1059
#17 0x0808fec4 in continue_command (proc_count_exp=0x0, from_tty=1) at infcmd.c:413
#18 0x080cf627 in execute_command (p=0x821a814 "", from_tty=1) at top.c:789
#19 0x0809c2b6 in command_handler (command=0x821a810 "cont") at event-top.c:513
#20 0x0809ca5b in command_line_handler (rl=0x85260a0 "àôQ\bðãQ\b\020") at event-top.c:809
#21 0x08181842 in rl_callback_read_char () at callback.c:114
#22 0x0809b93b in rl_callback_read_char_wrapper (client_data=0x0) at event-top.c:164
#23 0x0809c16e in stdin_event_handler (error=0, client_data=0x0) at event-top.c:420
#24 0x080e81e8 in handle_file_event (event_file_desc=0) at event-loop.c:706
#25 0x080e7cd6 in process_event () at event-loop.c:335
#26 0x080e7d19 in gdb_do_one_event (data=0x0) at event-loop.c:372
#27 0x080cf131 in catch_errors (func=0x80e7cf0 <gdb_do_one_event>, args=0x0, errstring=0x81c18c0 "",
    mask=6) at top.c:472
#28 0x080e7d5c in start_event_loop () at event-loop.c:408
#29 0x0809bab5 in cli_command_loop () at event-top.c:194
#30 0x08070588 in captured_command_loop (data=0x0) at main.c:102
#31 0x080cf131 in catch_errors (func=0x8070570 <captured_command_loop>, args=0x0,
    errstring=0x8194ea2 "", mask=6) at top.c:472
#32 0x08070fe3 in captured_main (data=0xbffff784) at main.c:724
#33 0x080cf131 in catch_errors (func=0x80705c0 <captured_main>, args=0xbffff784,
    errstring=0x8194ea2 "", mask=6) at top.c:472
#34 0x08071017 in main (argc=2, argv=0xbffff7fc) at main.c:735
#35 0x400adc6f in __libc_start_main () from /lib/libc.so.6
(top-gdb) print $xmm0
$8 = {f = {0, 0, 0, 0}}
(top-gdb) cont
Continuing.

Breakpoint 4, fetch_fpxregs (tid=31631) at i386-linux-nat.c:472
472       if (! have_ptrace_getfpxregs)
(top-gdb) cont
Continuing.

Program received signal SIGINT, Interrupt.
0x40414631 in nanosleep () from /lib/libc.so.6
(gdb) print $xmm0
$3 = {f = {-nan(0x7fffff), -nan(0x7fffff), -nan(0x7fffff), -nan(0x7fffff)}}
(gdb)