|
From: Michael E. <Mic...@co...> - 2011-08-30 22:43:23
|
We're hoping to do some algorithm profiling on our ARM Cortex-A8 based SOC, have had no problem building and running Valgrind 3.6.1 for our platform, but in all cases when running the tool even on very simple console mode "Hello World" applications, we're immediately getting a SIGILL crash on what appears to be the _start function in ucLibc before hitting any of our code. We're building ucLibc using the generic ARM option (there isn't a Cortex-A8 buildroot option), but I was under the general impression that it's valgrind that requires Cortex-A8, which is how we've built it, that a library such as ucLibc or other application built using a generic ARM instruction set should be able to be executed. Here's the sort of thing we're running into, would appreciate any suggestions for what might be going on, we're completely stuck at this point... # valgrind -v ./diftDec dift_422cmode2_no_hdr.data output.dat -hdr -f 422 ==483== Memcheck, a memory error detector ==483== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==483== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==483== Command: ./diftDec dift_422cmode2_no_hdr.data output.dat -hdr -f 422 ==483== --483-- Valgrind options: --483-- --suppressions=/usr/lib/valgrind/uclibc.supp --483-- -v --483-- Contents of /proc/version: --483-- Linux version 2.6.32 (Sri@Sri-Northstar) (gcc version 4.4.3 (Buildroot 2010.02) ) #5 PREEMPT Thu Aug 25 18:19:36 PDT 2011 --483-- Arch and hwcaps: ARM, ARMv7 --483-- Page sizes: currently 4096, max supported 4096 --483-- Valgrind library directory: /usr/lib/valgrind --483-- Reading syms from /dift/diftDec (0x8000) --483-- Reading syms from /lib/ld-uClibc-0.9.30.2.so (0x4000000) --483-- object doesn't have a symbol table --483-- Reading syms from /usr/lib/valgrind/memcheck-arm-linux (0x38000000) --483-- object doesn't have a symbol table --483-- object doesn't have a dynamic symbol table --483-- Reading suppressions file: /usr/lib/valgrind/uclibc.supp --483-- Reading suppressions file: /usr/lib/valgrind/default.supp ==483== ==483== Process terminating with default action of signal 4 (SIGILL) ==483== Illegal opcode at address 0x380AC1A8 ==483== at 0x4000960: _start (in /lib/ld-uClibc-0.9.30.2.so) ==483== ==483== HEAP SUMMARY: ==483== in use at exit: 0 bytes in 0 blocks ==483== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==483== ==483== All heap blocks were freed -- no leaks are possible ==483== ==483== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==483== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Illegal instruction # Conexant E-mail Firewall (Conexant.Com) made the following annotations --------------------------------------------------------------------- ********************** Legal Disclaimer **************************** "This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you." ********************************************************************** --------------------------------------------------------------------- |
|
From: Howard C. <hy...@sy...> - 2011-08-30 23:07:49
|
Michael Eskin wrote: > We’re hoping to do some algorithm profiling on our ARM Cortex-A8 based SOC, > have had no problem building and running Valgrind 3.6.1 for our platform, but > in all cases when running the tool even on very simple console mode “Hello > World” applications, we’re immediately getting a SIGILL crash on what appears > to be the _start function in ucLibc before hitting any of our code. We’re > building ucLibc using the generic ARM option (there isn’t a Cortex-A8 > buildroot option), but I was under the general impression that it’s valgrind > that requires Cortex-A8, which is how we’ve built it, that a library such as > ucLibc or other application built using a generic ARM instruction set should > be able to be executed. If your code is single-threaded you can get good profiling info using FunctionCheck. http://highlandsun.com/hyc/#fncchk If multithreaded, the function entry/exit counters will still be correct but time spent in functions will probably be incorrect. For a single-core system it will be close; for multi-core it will be totally bogus. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ |
|
From: John R. <jr...@bi...> - 2011-08-30 23:20:33
|
> ==483== Process terminating with default action of signal 4 (SIGILL)
> ==483== Illegal opcode at address 0x380AC1A8
> ==483== at 0x4000960: _start (in /lib/ld-uClibc-0.9.30.2.so)
Don't be so lame. Show us the contents of relevant memory!
In this case, the words at 0x380AC1A8 and at 0x4000960, and
preferably a couple words on either side of both addresses, too.
0x380AC1A8 ought to be inside one of the pieces of valgrind or memcheck.
Such a piece is statically linked at 0x38000000; for example see
valt_load_address_pri_norml="0x38000000"
VALT_LOAD_ADDRESS_PRI = 0x38000000
and similar in the source tree (configure, Makefile, etc.) for valgrind.
Also see:
readelf --headers $prefix/lib/valgrind/memcheck-<arch>-<os>
--
|
|
From: Julian S. <js...@ac...> - 2011-08-31 09:43:23
|
That's a bit strange, considering that it does work well on the A8. There must be something a bit funny about your setup. I wonder if it is to do with ucLibc. Or something alignment related, maybe. w.r.t. your SoC, what capabilities does the CPU have? Neon? VFP? > ==483== Process terminating with default action of signal 4 (SIGILL) > ==483== Illegal opcode at address 0x380AC1A8 > ==483== at 0x4000960: _start (in /lib/ld-uClibc-0.9.30.2.so) It would be useful to know what instruction is at 0x380AC1A8. I can't guess whether that is part of the main valgrind executable or whether it is code generated by valgrind's JIT. Can you objdump -d of memcheck-arm-linux and see if you can find that address? If not, you'll have to be a remote debug server :-) Try running with the flags --trace-flags=10001110 --trace-notbelow=0. This will generate a huge amount of output, but it should make it possible to make some sense of what's going on at 0x380AC1A8 and/or 0x4000960. Bear in mind you can't post more than 40k of message to the list, so you may have to do some pruning. J |