|
From: Bob K. <Bo...@ri...> - 2014-04-07 20:26:42
|
Hello valgrind-users, We are currently using valgrind at work by putting the debug symbols onto the appliance at test time and running our process under valgrind. The log output contains the correct stack trace as expected. Setting up the appliance for this kind of testing is non-trivial, especially getting the debug symbols in place. Is it possible to run valgrind *without* the debug symbols available and then take the valgrind log output, the .map, and the debug symbols to get a full stack trace? That would simplify our testing greatly. Thanks, Bob |
|
From: Julian S. <js...@ac...> - 2014-04-07 21:45:40
|
On 04/07/2014 10:26 PM, Bob Kuo wrote: > Is it possible to run valgrind *without* the debug symbols available > and then take the valgrind log output, the .map, and the debug symbols > to get a full stack trace? That would simplify our testing greatly. In theory you might be able to use addr2line, but you'd need to do some arithmetic -- basically, subtract the library actual load address -- before you can give those addresses to addr2line. The usual problem with running V on embedded targets is (1) that it takes forever to move the debuginfo objects onto the target, and (2) doing so uses up all the flash storage on the target. If your target can communicate with the build host using TCP/IP, you might like to try running V's debuginfo server on the host (auxprogs/valgrind-di-server.c) and asking V on the target to use that, using --debuginfo-server=. It's pretty crude (needs work) but it does just about work. J |
|
From: Bob K. <Bo...@ri...> - 2014-04-08 16:10:54
|
On 4/7/14, 4:45 PM, "Julian Seward" <js...@ac...> wrote: >In theory you might be able to use addr2line, but you'd need to do some >arithmetic -- basically, subtract the library actual load address -- >before you can give those addresses to addr2line. Please excuse my ignorance - by "actual load address" do you mean something that would only be determined at run time like the base address from /proc/12345/maps? Or do I just need to do some arithmetic with the original binary, the debug symbols, and the map file? > >The usual problem with running V on embedded targets is (1) that it >takes forever to move the debuginfo objects onto the target, and (2) >doing so uses up all the flash storage on the target. If your target >can communicate with the build host using TCP/IP, you might like to try >running V's debuginfo server on the host (auxprogs/valgrind-di-server.c) >and asking V on the target to use that, using --debuginfo-server=. > >It's pretty crude (needs work) but it does just about work. Great, I'll take a look into this as well. > >J > |