bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gold/23842] New: "dwp -e" doesn't consult DW_AT_comp_dir attributes


From: m-srcware at bodyfour dot uk
Subject: [Bug gold/23842] New: "dwp -e" doesn't consult DW_AT_comp_dir attributes
Date: Mon, 29 Oct 2018 15:13:48 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=23842

            Bug ID: 23842
           Summary: "dwp -e" doesn't consult DW_AT_comp_dir attributes
           Product: binutils
           Version: 2.32 (HEAD)
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gold
          Assignee: ccoutant at gmail dot com
          Reporter: m-srcware at bodyfour dot uk
                CC: ian at airs dot com
  Target Milestone: ---

Created attachment 11372
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11372&action=edit
trivial program with static libraries and build script

Forgive me if this is user error; I am new to -gsplit-dwarf.  However I am
having trouble making "dwp" work, even in the latest git version.

I am trying to use "dwp" on an executable built from dozens of individual
static libraries, each built in a different directory.  Since they were each
built with -gsplit-dwarf, this means that the executable's .debug_info section
has a large number of DW_TAG_compile_unit entries each with a
DW_AT_GNU_dwo_name/DW_AT_comp_dir pair.

It seems that when using "dwp -e" it tries to look for these DW_AT_GNU_dwo_name
but assumes that they're relative to the current directory, rather than
DW_AT_comp_dir.  Since they're not all originating from the same directory this
means that no matter where I run the command from it won't find them all!

Listing all of the *.dwo files manually on the command line isn't all that
practical because there are a lot of libraries with optionally compiled-in
bits.  I guess for now I'll hack together a script that parses the output of
objdump to find them all, but I think this is something "dwp -e" should handle.

To make reproduction easy, I'm attaching a trivial example of an executable
which gets built with references to three *.dwo files in separate directories. 
Here is what I get when I use it:


$ cd split-dwarf-multidir
$ ./compile.sh
$ objdump --dwarf=info exe/exe | egrep 'DW_AT_GNU_dwo_name|DW_AT_comp_dir'
    <20>   DW_AT_GNU_dwo_name: (indirect string, offset: 0x0): exe.dwo
    <24>   DW_AT_comp_dir    : (indirect string, offset: 0x8):
/home/mitch/split-dwarf-multidir/exe
    <54>   DW_AT_GNU_dwo_name: (indirect string, offset: 0x53): a.dwo
    <58>   DW_AT_comp_dir    : (indirect string, offset: 0x2d):
/home/mitch/split-dwarf-multidir/liba
    <88>   DW_AT_GNU_dwo_name: (indirect string, offset: 0x7f): b.dwo
    <8c>   DW_AT_comp_dir    : (indirect string, offset: 0x59):
/home/mitch/split-dwarf-multidir/libb
$ ~/git/binutils-gdb/gold/dwp -e exe/exe
/home/mitch/git/binutils-gdb/gold/dwp: error: cannot open exe.dwo: No such file
or directory
/home/mitch/git/binutils-gdb/gold/dwp: fatal error: exe.dwo: can't open
$ ( cd exe && ~/git/binutils-gdb/gold/dwp -e exe )
/home/mitch/git/binutils-gdb/gold/dwp: error: cannot open a.dwo: No such file
or directory
/home/mitch/git/binutils-gdb/gold/dwp: fatal error: a.dwo: can't open


Note that there is an unrelated bug (I think) where "objdump --dwarf=links
exe/exe" only prints the first dwo entry in the executable, but "--dwarf=info"
shows all of them so I think the executable is fine... it's just that "dwp"
isn't finding them correctly.  I'll file a separate bug about objdump

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]