|
From: Julian S. <js...@ac...> - 2013-06-07 16:55:28
|
Using Valgrind on phones or embedded targets in general can be
difficult because of its requirement to have the debuginfo objects
available in target's filesystem. For large apps this means pushing
many hundreds of megabytes of debug objects over slow connections to
the target. This is mostly a waste of time, because reading ELF
symbols, Dwarf CFI (unwind) and line number information typically
involves visiting less than 10% of the debuginfo object.
A secondary problem is that V naively assumes it can temporarily mmap
in the debug objects to read from them. For objects of gigabyte-size,
it may not be able to find enough address space, and so debuginfo
reading simply fails.
I have committed, in svn://svn.valgrind.trunk/valgrind/branches/DISRV,
code to solve both problems. It removes the assumption that the
debuginfo objects are mapped in, instead accessing them through an
abstract type (DiImage) which can be connected either to a local file
(as before) or to a simple server over TCP/IP. This now works for
Linux and Android, but does not do Stabs or Dwarf-1.
To use, build as normal. Run the program
auxprogs/valgrind-di-server in the host directory containing the
objects to be served. Start V on the target in the usual way,
but give the flag --debuginfo-server=ip.addr.of.host:1500. It
should then query the server as you'd expect.
Debuginfo is transferred between server and client in compressed
16K chunks and a small amount (32 chunks worth) is cached in the
client. For a debug object of 1160MB, it can transfer the
relevant info in about 2.5 minutes over an 11g (one-hop) link,
which is worse than I expected, but still an improvement on
moving the whole object around.
The caching mechanism is also used for local files, so the old
mmap-it-all-in scheme is gone permanently.
Feedback welcome. There are some caveats:
* the build system builds the server for the target, not the
host, which is not what you want. You'll need to rebuilt it
by hand, thusly:
gcc -Wall -g -O -o valgrind-di-server auxprogs/valgrind-di-server.c \
-Iinclude -Icoregrind -IVEX/pub -DVGA_amd64 -DVGO_linux
* Linux and Android only right now. No Dwarf1 or Stabs.
(Does anybody use those any more?)
* Proper debuglink CRC32 checking is done even in the remote case;
however that's temporarily disabled. So it will load a non-matching
debug object if you're not careful.
* PPC64-linux probably doesn't work. It's on the to-fix list.
* It makes loading local files a bit slower, although not much.
That can be tuned further, I think.
* If the remote server quits or vanishes whilst V is connected to it,
V will assert. No error recovery.
This turned out to be way more work than I expected, but it's mostly
done now.
J
|