This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: current CVS gdb and SSE xmm registers don't work
- To: Mark Kettenis <kettenis at wins dot uva dot nl>
- Subject: Re: current CVS gdb and SSE xmm registers don't work
- From: Felix Buenemann <atmosfear at users dot sf dot net>
- Date: Tue, 24 Jul 2001 00:37:54 +0200
- Cc: gdb-patches at sourceware dot cygnus dot com
- References: <01071511090404.13471@astral> <0107161721020D.13471@astral> <200107162059.f6GKxr805474@delius.kettenis.local>
- Reply-To: Felix dot Buenemann at gmx dot de
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