|
From: Loïc M. <lo...@do...> - 2010-03-15 09:50:42
|
Hi folks
valgrind recently got ported to ARM (nice work!), and it *builds* fine
on Ubuntu 10.04:
https://launchpad.net/ubuntu/+source/valgrind/1:3.6.0~svn20100212-0ubuntu3/+build/1562251
sadly, it's unusable as it SIGILLs in _start() on startup:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/537458
I suspect the very early init code needs porting to Thumb(-2); perhaps
the valgrind code needs a bunch of fixes to run Thumb(-2) binaries?
(We default to ARMv7 in Thumb-2 mode in Ubuntu 10.04).
Is this in the works, or should we consider removing it from Ubuntu on
armel for this release and look back next cycle?
Thanks!
--
Loïc Minier
|
|
From: Alexander P. <gl...@go...> - 2010-03-15 10:33:40
|
Unfortunately the bug report lacks the full log of Valgrind's run, especially the bytes containing the unhandled instruction, so it's hard to tell what causes the problem. In fact Valgrind doesn't claim to support the full ARMv7 (even v6) instruction set, so you may experience problems with the tests using those. For example, newer systems tend to use the userspace memory barriers, which are not supported by Valgrind yet, within ld.so (see https://bugs.kde.org/show_bug.cgi?id=228060). Personally I've had problems with those running ld.so version 2.10.1 on the 2.6.31 kernel, whereas ld.so v. 2.9 and kernel 2.6.29 seemed to work ok. On Mon, Mar 15, 2010 at 12:27 PM, Loïc Minier <lo...@do...> wrote: > Hi folks > > valgrind recently got ported to ARM (nice work!), and it *builds* fine > on Ubuntu 10.04: > https://launchpad.net/ubuntu/+source/valgrind/1:3.6.0~svn20100212-0ubuntu3/+build/1562251 > > sadly, it's unusable as it SIGILLs in _start() on startup: > https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/537458 > > I suspect the very early init code needs porting to Thumb(-2); perhaps > the valgrind code needs a bunch of fixes to run Thumb(-2) binaries? > (We default to ARMv7 in Thumb-2 mode in Ubuntu 10.04). > > Is this in the works, or should we consider removing it from Ubuntu on > armel for this release and look back next cycle? > > Thanks! > -- > Loïc Minier > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > -- Alexander Potapenko Software Engineer Google Moscow |
|
From: Loïc M. <lo...@do...> - 2010-03-15 10:56:47
|
On Mon, Mar 15, 2010, Alexander Potapenko wrote: > Unfortunately the bug report lacks the full log of Valgrind's run, > especially the bytes containing the unhandled instruction, so it's > hard to tell what causes the problem. I'm afraid it SIGILLs on the startup of valgrind itself: root@bee:/# valgrind.bin --help qemu: uncaught target signal 4 (Illegal instruction) - core dumped Illegal instruction (core dumped) (that's under qemu syscall emulation, but it's the same under qemu system emulation) Is there a way to get a longer log? Thanks for the details of ARM support, -- Loïc Minier |
|
From: Alexander P. <gl...@go...> - 2010-03-15 11:04:00
|
Sorry, I'm running V on a real ARM CPU and can't help with running QEMU. Maybe the emulator just doesn't let Valgrind know about the SIGILL thus making it impossible to print the report. For the particular bug I've pointed to above you can try to break on __kernel_dmb (0xffff0fa0) and see if the program reaches this breakpoint running natively (i.e. without Valgrind) On Mon, Mar 15, 2010 at 1:56 PM, Loïc Minier <lo...@do...> wrote: > On Mon, Mar 15, 2010, Alexander Potapenko wrote: >> Unfortunately the bug report lacks the full log of Valgrind's run, >> especially the bytes containing the unhandled instruction, so it's >> hard to tell what causes the problem. > > I'm afraid it SIGILLs on the startup of valgrind itself: > root@bee:/# valgrind.bin --help > qemu: uncaught target signal 4 (Illegal instruction) - core dumped > Illegal instruction (core dumped) > > (that's under qemu syscall emulation, but it's the same under qemu > system emulation) > > Is there a way to get a longer log? > > Thanks for the details of ARM support, > -- > Loďc Minier > -- Alexander Potapenko Software Engineer Google Moscow |
|
From: Alexander P. <gl...@go...> - 2010-03-15 11:13:06
|
> root@bee:/# valgrind.bin --help Oh, I've missed your command line. This should have nothing to do with the ld.so or any code executed under Valgrind, it's possibly the Valgrind binary itself. How about dumping the list of instructions used by the binary (objdump -d valgrind) and making a test that uses them? Alex |
|
From: Loïc M. <lo...@do...> - 2010-03-16 14:43:10
|
On Mon, Mar 15, 2010, Alexander Potapenko wrote:
> Oh, I've missed your command line. This should have nothing to do with
> the ld.so or any code executed under Valgrind, it's possibly the
> Valgrind binary itself. How about dumping the list of instructions
> used by the binary (objdump -d valgrind) and making a test that uses
> them?
Thanks; so gdb reports the crash at 0x3801eb34 in _start in
/usr/lib/valgrind/memcheck-arm-linux; in the objdump -d output, I see
that it's on the mvn instruction, see coregrind/m_main.c:
#elif defined(VGP_arm_linux)
asm("\n"
"\t.align 2\n"
"\t.global _start\n"
"_start:\n"
"\tldr r0, [pc, #36]\n"
"\tldr r1, [pc, #36]\n"
"\tadd r0, r1, r0\n"
"\tldr r1, [pc, #32]\n"
"\tadd r0, r1, r0\n"
"\tmvn r1, #15\n"
"\tand r0, r0, r1\n"
"\tmov r1, sp\n"
"\tmov sp, r0\n"
"\tmov r0, r1\n"
"\tb _start_in_C_linux\n"
"\t.word vgPlain_interim_stack\n"
"\t.word "VG_STRINGIFY(VG_STACK_GUARD_SZB)"\n"
"\t.word "VG_STRINGIFY(VG_STACK_ACTIVE_SZB)"\n"
);
Apparently, mvn isn't available in T2 mode.
--
Loïc Minier
|