[pacman-dev] Pacman split debug info symbol path

[Steven Noonan]

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'.

>> >>
>> >> 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
>> >>
>> >
>>
>