Created attachment 75511 [details] include-debugsyms-path-v2.patch This is v2 of my patch. It was reworked to be a lot simpler, taking Tom's suggestion to require the user to specify the full path to the debug objects. Usage (from log file): --6949-- Valgrind options: --6949-- --suppressions=/usr/lib/valgrind/debian-libc6-dbg.supp --6949-- -v --6949-- --leak-check=full --6949-- --num-callers=40 --6949-- --log-file=valgrind.log --6949-- --track-origins=yes --6949-- --include-debugsyms-path=/tmp/tmpXpCdEW/usr/lib/debug Original summary: This is a patch that teaches valgrind how to search a user-specified path for debug symbols. The use cases are: - user may not have superuser permissions to install debug packages on their system. - even if user does have sudo, user might not want to install 10s (or 100s) of debug packages on their system - same as above but replace user with 'nightly automation script' Original discussion here: http://thread.gmane.org/gmane.comp.debugging.valgrind.devel/21118
Alex, thanks for the patch. Sorry to arrive late to the discussion. Patch looks good. One question about its behaviour, though. As you noticed, on Android I added an ad-hoc hack which looks for debuginfo for /foo/bar/xyzzy.so in /sdcard/symbols/foo/bar/xyzzy.so. In other words, it adds the prefix "/sdcard/symbols" to full path of the object to the prefix and not just the to object's filename -- in which case it would look for "/sdcard/symbols/xyzzy.so". Does your patch behave the same? The real question is: can the patch be used as a direct replacement for the Android hack, if I give the argument --include-debugsyms-path=/sdcard/symbols ? One final minor comment is, I think I would prefer to use the name --extra-debuginfo-path=, so as to avoid the possibility of confusing (presumably already confused) users into thinking that this is somehow related to include files. Which it isn't.
Created attachment 75553 [details] include-debugsyms-path-v3.patch Hi Julian, I've updated the patch to use your suggested name. As to whether the patch can replace the android hack directly, the answer is "maybe". One difference in the ad hoc search vs. the normal search is in the calls to dinfo_zalloc(). I confess, the differences in the arguments "di.fdf.2", "di.fdf.3", and "di.fahdi.1" are a complete mystery to me. I tried grokking the arena_malloc() code but failed completely. I would say that if a "charge center" has nothing to do with some path encoded in an elf header, then yes, the new argument could be used as a direct replacement for the ad hoc symbol searching function. You could pass --extra-debuginfo-path=/sdcard/symbols/ and it should pick up "/foo/bar/xyzzy.so" from the object. Hopefully that question doesn't block this particular patch from going in though. :) Thanks!
Committed, r13154. Thanks for the patch. Need to add a fix to the documentation before closing.
Documentation patch sent via email and applied to trunk as r13169. Closing out bug.