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

[Felix Buenemann]

[Resend Mail, last send was on 2001-07-24 and no reaction yet. Send to Mark, 
Andrew and gdb-patches]

Hi,

sorry for the slow answer but I was very busy.

On Monday, 16. July 2001 22:59, Mark Kettenis wrote:
>    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)
>
> Yes please.  From what I see in the backtrace everything is
> functioning OK.  It would be interesting to know the value of
> have_ptrace_getfpxregs.  It should be 1 on the first entry of
> fetch_fpxregs().  Then it would be interesting to see the result the
> result of the ptrace() call later on in fetch_fpxregs().  Please check
> (with ps) that the program with PID equal to the first argument to
> ptrace() does realy exist.  I suspect ptrace() will fail with EIO,
> which GDB interprets as a lack of support for SSE registers in the
> kernel.  This makes GDB set have_ptrace_getfpxregs to zero and gives
> you the dummy register values you're seeing.  In that case, either
> your kernel doesn't include SSE support, or there is a bug in your
> kernel.  In the latter case, please report this to the linux-kernel
> mailing list.

hmm the code seems to behave quite strange, I found out the following:
have_ptrace_getfpxregs will be always 1 this means that the ptrace call never
fails (at least not with errno == EIO. On breakpoint trigger for
fetch_fpxregs() I have the following:

Breakpoint 1, fetch_fpxregs (tid=1863) at i386-linux-nat.c:472
1863 is the correct PID of the mplayer process, now when I print out tid I
get:
(gdb) p tid
$4 = 136444668
This is the value that will be passed as second argument to ptrace() call,
but although I think this value is not correct, ptrace call will not fail and
set have_ptrace_getfpxregs or give error message:
 483       perror_with_name ("Couldn't read floating-point and SSE
registers");

IMHO tid passed to fetch_fpxregs() and tid passed to ptrace() should be
identical, shouldn't they?

> From your backtrace I deduced that you are debugging multithreaded
> programs.  Are you by any chance using an SMP system.  I've had a
> recent FPU related bug report that seems to be caused by a SMP kernel
> bug.

No I have no SMP system, this is PIII Coppermine 850 Notebook running Linux
2.4.4 kernel.
--
Best Regards,
   Felix