|
From: Randy M. <rwm...@gm...> - 2006-05-09 20:11:32
|
Hi,
On 5/5/06, Julian Seward <js...@ac...> wrote:
>
> > > If I run objdump on my test program, I see that the instruction is:
> > > 10001d24: 7d 20 4e 2c lhbrx r9,r0,r9
> >
> > Fixed (vex r1608).
>
> I also did sthbrx. So {ld,st}{h,w}brx should now work.
Thanks, those changes work great.
I can now run valgrind on my embedded ppc apps!
Now to add to the suppressions list...
The altivec probing/signal handling is a bug in our 2.4.22 kernel.
I'm running on a G4 system but (for historical reasons) the
kernel hasn't been compiled with CONFIG_ALTIVEC.
This patch/email: <http://lkml.org/lkml/2004/5/15/19>
explains that older linux kernels didn't
handle a user-mode altivec instruciton being called
on a kernel without CONFIG_ALTIVEC.
I assume that valgrind doesn't want to worry about
a 2.4.22 bug.
I'll include my testvg.c code in case someone else
runs into this sort of problem.
// Randy
I've extracted a simple test program (attached) and see the vector
instruction generates a sigtrap rather than a sigill.
(I'm running 2.4.22 + patches --
don't talk to me about how old the kernel is, or my head will explode ;-) =
)
% gcc -static -o testvg-static testvg.c
# ./testvg-static
test float
done float
test fsqrt
sigill fsqrt
test frsqrte
done frsqrte
test altivec
Trace/breakpoint trap (core dumped)
[root@10.0.7.1 tmp]# dmesg -c
Bad trap at PC: 100006ec, SR: f932, vector=3Df00
On a ppc405 (no Altivec), I get the sigill altivec path.
All this makes sense if you read: <http://lkml.org/lkml/2004/5/15/19>
|