What steps will reproduce the problem?
1. Create a file structure of
src/base.h
src/main.c
src/a/a.[cc, h]
src/b/b.[cc, h]
2. Have a.cc #include "a.h" and "../base.h"
3. Have b.cc #include "b.h", "../base.h", and "../a/a.h"
4. cd src/a && [compile] a.cc -> a.o
5. cd src/b && [compile] b.cc -> b.o
6. cd src/ && [compile] main.cc -> main.o
7. cd src/ && [link] main.o a/a.o b/b.o -> main[.executable]
8. dump_syms on main
What is the expected output? What do you see instead?
[Depending on the compiler?], one or more of the #includes will result in a
Statement Program Prologue (Dwarf 2.0, 6.2.4) whose file_names (6.2.4.11) are
relative to the DW_at_comp_dir of the current compilation unit (noted by the
LEB128(0) for the directory index of the file_names)
What version of the product are you using? On what operating system?
ToT / [Mac, Linux]
Please provide any additional information below.
In src/common/dwarf_line_to_module.cc, DwarfLineToModule::DefineFile() only
stores the relative path of the file if its dir_num is 0. At no point is the
DW_AT_comp_dir taken into consideration.
Because dump_syms operates at a Module level (which encompasses multiple
compilation units), the relative paths of these files cannot be reliably
reconstituted to their absolute paths, because the association to the
compilation unit is discarded by the Module.
For post-processing Breakpad sym files, such as for rewriting FILE entries with
source server annotations, the loss of the full path means / compilation unit
association means that the original path on disk cannot be recovered, and thus
cannot be annotated.
Instead of discarding the compilation dir, the LineInfoHandler should be
informed of the compilation unit, so that the full path can be reconstituted
when adding the files to the Module.
Original issue reported on code.google.com by rsleevi@chromium.org on 25 Apr 2012 at 7:36
Original issue reported on code.google.com by
rsleevi@chromium.orgon 25 Apr 2012 at 7:36