[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.
- [Bug gold/23842] New: "dwp -e" doesn't consult DW_AT_comp_dir attributes,
m-srcware at bodyfour dot uk <=