|
From: David E. <eg...@ha...> - 2004-06-09 02:15:58
|
Dear Paul,
I've downloaded your PowerPC port of valgrind 2.1.0, and am running into
an "Illegal opcode" error when it hits an addis instruction in libgobject.
Valgrind does have a section for generating "addis" UCode instructions,
so I'm a bit lost. See dump below.
I've also tried pulling the latest CVS and applying your CVS patch.
After I got valgrind built, I got:
eger@rosencrantz$ valgrind ls
Executable is mapped outside of range 0x1009e000-0x7ffff000
failed to load /usr/local/lib/valgrind/stage2: Cannot allocate memory
Any ideas? If you give me a pointer to what needs fixing, I could look
at it. I'm just a little unsure where to start.
-dte
==15814== Memcheck, a memory error detector for linux.
==15814== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==15814== Using valgrind-2.1.0-ppc, a program supervision framework for linux.
==15814== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==15814== PowerPC port copyright (C) 2004, and GNU GPL'd, by Paul Mackerras.
==15814== Estimated timebase clock rate is 33 MHz
==15814== For more details, rerun with: -v
==15814==
unrecognized PowerPC instruction: 7CBA04AA
at 0xF3BA1B4: (within /usr/lib/libgobject-2.0.so.0.400.0)
==15814==
==15814== Process terminating with default action of signal 4 (SIGILL): dumping core
==15814== Illegal opcode at address 0xFDE8BC8
==15814== at 0xF3BA1B4: (within /usr/lib/libgobject-2.0.so.0.400.0)
==15814== by 0xF3C0E30: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.400.0)
==15814== by 0xF3C0EF4: g_type_init (in /usr/lib/libgobject-2.0.so.0.400.0)
==15814== by 0xF5C0234: (within /usr/lib/libgdk-x11-2.0.so.0.400.0)
==15814==
==15814== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==15814== malloc/free: in use at exit: 8157 bytes in 54 blocks.
==15814== malloc/free: 58 allocs, 4 frees, 8236 bytes allocated.
==15814== For a detailed leak analysis, rerun with: --leak-check=yes
==15814== For counts of detected errors, rerun with: -v
Illegal instruction
|
|
From: Paul M. <pa...@sa...> - 2004-06-09 03:21:54
|
David, > I've downloaded your PowerPC port of valgrind 2.1.0, and am running into > an "Illegal opcode" error when it hits an addis instruction in libgobject. > Valgrind does have a section for generating "addis" UCode instructions, > so I'm a bit lost. See dump below. The instruction is 7CBA04AA, which is a lswi instruction. I do need to get in and implement the string load/store instructions. I have avoided them so far because I haven't hit the problem myself, and because doing lswx/stswx is going to be a bit interesting - uCode doesn't have a way to express loading a variable number of registers based on the contents of another register (XER). > I've also tried pulling the latest CVS and applying your CVS patch. > After I got valgrind built, I got: > > eger@rosencrantz$ valgrind ls > Executable is mapped outside of range 0x1009e000-0x7ffff000 > failed to load /usr/local/lib/valgrind/stage2: Cannot allocate memory Hmmm, I'll have to look at that. What address is valgrind linked at? You could find out by doing `objdump -p valgrind'. It may be that I arranged for it to be linked in the 0xb0000000 region, in which case you would need to change that to the 0x70000000 region. The best address to use there depends on the TASK_SIZE definition in the kernel, and it looks like you have TASK_SIZE=0x80000000 (2GB). I usually have TASK_SIZE set to 3GB on my ppc32 machines, and of course 32-bit processes have TASK_SIZE = 4GB on a ppc64 kernel. Regards, Paul. |
|
From: Paul M. <pa...@sa...> - 2004-06-21 12:50:08
|
Nicholas Nethercote writes: > On Wed, 9 Jun 2004, Paul Mackerras wrote: > > > I do need to get in and implement the string load/store instructions. > > I have avoided them so far because I haven't hit the problem myself, and > > because doing lswx/stswx is going to be a bit interesting - uCode > > doesn't have a way to express loading a variable number of registers > > based on the contents of another register (XER). > > Sounds similar to the REP prefixed x86 instructions, which are done with a > JIFZ loop. It's not currently obvious to me how I get it to use a different register each time around the loop... I guess I could write a helper in C, but then it would presumably need to know about the instrumentation, or the instrumentation would need to know about it. Paul. |
|
From: Nicholas N. <nj...@ca...> - 2004-06-21 13:15:31
|
On Mon, 21 Jun 2004, Paul Mackerras wrote: > > Sounds similar to the REP prefixed x86 instructions, which are done with a > > JIFZ loop. > > It's not currently obvious to me how I get it to use a different > register each time around the loop... Hmm, I see. What a sucky pair of instructions. You could do an awful hack of writing all registers to somewhere in memory and then looping through them that way. (Hoping the instructions aren't used very much, because it'll give awful performance.) Something similar is currently done for the even-more-sucky x86 bt[src] instructions. N |
|
From: Nicholas N. <nj...@ca...> - 2004-06-21 11:37:09
|
On Wed, 9 Jun 2004, Paul Mackerras wrote: > I do need to get in and implement the string load/store instructions. > I have avoided them so far because I haven't hit the problem myself, and > because doing lswx/stswx is going to be a bit interesting - uCode > doesn't have a way to express loading a variable number of registers > based on the contents of another register (XER). Sounds similar to the REP prefixed x86 instructions, which are done with a JIFZ loop. N |