[pacman-dev] Pacman split debug info symbol path
Steven Noonan
steven at uplinklabs.net
Sat Mar 29 14:15:38 EDT 2014
On Sat, Mar 29, 2014 at 11:04 AM, Steven Noonan <steven at uplinklabs.net> wrote:
> On Sat, Mar 29, 2014 at 11:00 AM, Dave Reisner <d at falconindy.com> wrote:
>> On Mar 29, 2014 1:52 PM, "Steven Noonan" <steven at uplinklabs.net> wrote:
>>>
>>> On Sat, Mar 29, 2014 at 10:41 AM, Dave Reisner <d at falconindy.com> wrote:
>>> > On Mar 29, 2014 1:36 PM, "Steven Noonan" <steven at uplinklabs.net> wrote:
>>> >>
>>> >> Hi folks,
>>> >>
>>> >> I think the directory Pacman is using for the split-out debug symbols
>>> >> is incorrect. This appears to be needed:
>>> >
>>> > Why do you think this? What are the symptoms you're seeing? I use debug
>>> > packages all the time and they work as expected.
>>>
>>> I've seen tools complain they can't find debug symbols or simply not show
>> any.
>>>
>>> What tools have you used successfully? perf, gdb, and oprofile all
>>> seem to look in the 'debug-id' directory, not in 'debug_id'...
>>
>> gdb and valgrind, mostly. I've not seen either complain about missing
>> symbols.
>
> Hmm. It would be interesting to get an strace of gdb/valgrind on your
> system and see if it's really opening/reading those files, because
> based on my inspection of perf/oprofile/gdb sources, they don't know
> about '.build_id'.
Looking through the valgrind sources (via svn), they have a
find_buildid function which also looks in '.build-id'. They also link
to this page in a comment above the function:
http://fedoraproject.org/wiki/RolandMcGrath/BuildID
This page also references '.build-id' rather than '.build_id'.
>>> >>
>>> >> commit 61ed104abf95ac38e7d317c760807f308ea90555
>>> >> Author: Steven Noonan <steven at uplinklabs.net>
>>> >> Date: Wed Feb 12 05:44:16 2014 -0800
>>> >>
>>> >> makepkg: use dash instead of underscore in /usr/lib/debug/.build-id
>>> >>
>>> >> Signed-off-by: Steven Noonan <steven at uplinklabs.net>
>>> >>
>>> >> diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
>>> >> index 027fcc3..7e663af 100644
>>> >> --- a/scripts/makepkg.sh.in
>>> >> +++ b/scripts/makepkg.sh.in
>>> >> @@ -1525,7 +1525,7 @@ strip_file() {
>>> >>
>>> >> # has this file already been stripped
>>> >> if [[ -n "$bid" ]]; then
>>> >> - if [[ -f
>>> >> "$dbgdir/.build_id/${bid:0:2}/${bid:2}.debug" ]]; then
>>> >> + if [[ -f
>>> >> "$dbgdir/.build-id/${bid:0:2}/${bid:2}.debug" ]]; then
>>> >> return
>>> >> fi
>>> >> elif [[ -f "$dbgdir/$binary.debug" ]]; then
>>> >> @@ -1546,15 +1546,15 @@ strip_file() {
>>> >>
>>> >> if [[ -n "$bid" ]]; then
>>> >> local target
>>> >> - mkdir -p "$dbgdir/.build_id/${bid:0:2}"
>>> >> + mkdir -p "$dbgdir/.build-id/${bid:0:2}"
>>> >>
>>> >> target="../../../../../${binary#./}"
>>> >> target="${target/..\/..\/usr\/lib\/}"
>>> >> target="${target/..\/usr\/}"
>>> >> - ln -s "$target"
>>> > "$dbgdir/.build_id/${bid:0:2}/${bid:2}"
>>> >> + ln -s "$target"
>>> > "$dbgdir/.build-id/${bid:0:2}/${bid:2}"
>>> >>
>>> >> target="../../${binary#./}.debug"
>>> >> - ln -s "$target"
>>> >> "$dbgdir/.build_id/${bid:0:2}/${bid:2}.debug"
>>> >> + ln -s "$target"
>>> >> "$dbgdir/.build-id/${bid:0:2}/${bid:2}.debug"
>>> >> fi
>>> >> fi
>>> >>
>>> >> To justify this change, I can't find any tools that actually look in
>>> >> 'build_id' (with an underscore) when searching for symbols.
>>> >>
>>> >> For example, perf does this (lines 101, 105):
>>> >>
>>> >>
>>> >
>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/tools/perf/util/build-id.c#n92
>>> >>
>>> >> GDB also looks in '.build-id' (lines 83, 102):
>>> >>
>>> >>
>>> >
>> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/build-id.c;h=491900b3e545c72325a54fc79847b8872fa63aae;hb=HEAD#l73
>>> >>
>>> >> OProfile, same issue (lines 93, 104):
>>> >>
>>> >>
>>> >
>> http://sourceforge.net/p/oprofile/oprofile/ci/master/tree/libutil++/bfd_support.cpp
>>> >>
>>> >> I noticed tool breakage back when I submitted the kernel module
>>> >> split+debug patch, but kept the patch to myself because I figured I
>>> >> must have been missing the rationale for the difference, but I've been
>>> >> so far unable to find any.
>>> >>
>>> >> - Steven
>>> >>
>>> >
>>>
>>
More information about the pacman-dev
mailing list