This is an archive of the discontinued LLVM Phabricator instance.

Reuse code from CGDebugInfo::getOrCreateFile() when creating the file for the DICompileUnit
ClosedPublic

Authored by aprantl on Dec 10 2018, 9:43 AM.

Details

Summary

This addresses post-commit feedback for D55085. Without this patch, a main source file with an absolute paths may appear in different DIFiles, once with the absolute path and once with the common prefix between the absolute path and the current working directory.

Diff Detail

Repository
rL LLVM

Event Timeline

aprantl created this revision.Dec 10 2018, 9:43 AM

If I change what I think is two typos, then the patch compiles for me and solves the issue I had.

The remaining calls to DIBuilder::createFile, should they be changed to createFile too or should they be left as is for some reason?
If they should be left, perhaps it would be good to add some comments explaining why we should use DIBuilder::createFile directly in some place and not in others?

Thanks!

lib/CodeGen/CGDebugInfo.cpp
432 ↗(On Diff #177544)

I suppose you mean to use the new
createFile
method here?

613 ↗(On Diff #177544)

I suppose you mean to use the new
createFile
method here?

I also removed the other references to DIBuilder::createFile() in r348866.

This revision was not accepted when it landed; it landed in state Needs Review.Dec 11 2018, 9:03 AM
This revision was automatically updated to reflect the committed changes.

Great, thanks!

labath added a subscriber: labath.Dec 13 2018, 8:22 AM

I am sorry about the late notice Adrian, but it looks like this patch completely breaks DWO file lookup. I think the search for the common prefix of compilation directory and file path is somehow broken. For example this is what I get when compiling a file from /tmp with PWD=/home/pavel (so, these paths only share / as a prefix):

~ $ /tmp/clang.bad  -g -gsplit-dwarf  -c -o foo.o /tmp/foo.cpp 
~ $ llvm-dwarfdump foo.o 
foo.o:	file format ELF64-x86-64

.debug_info contents:
0x00000000: Compile Unit: length = 0x0000001c version = 0x0004 abbr_offset = 0x0000 addr_size = 0x08 (next unit at 0x00000020)

0x0000000b: DW_TAG_compile_unit
              DW_AT_stmt_list	(0x00000000)
              DW_AT_GNU_dwo_name	("foo.dwo")
              DW_AT_GNU_pubnames	(true)
              DW_AT_GNU_dwo_id	(0x441cbc2aa7bff7c5)
              DW_AT_GNU_addr_base	(0x00000000)

Notice that DW_AT_comp_dir is completely missing (so the debugger has no chance of finding the dwo file). If I revert this (and r348866) then I get correct behavior:

~ $ /tmp/clang.good  -g -gsplit-dwarf  -c -o foo.o /tmp/foo.cpp 
~ $ llvm-dwarfdump foo.o 
foo.o:	file format ELF64-x86-64

.debug_info contents:
0x00000000: Compile Unit: length = 0x00000020 version = 0x0004 abbr_offset = 0x0000 addr_size = 0x08 (next unit at 0x00000024)

0x0000000b: DW_TAG_compile_unit
              DW_AT_stmt_list	(0x00000000)
              DW_AT_GNU_dwo_name	("foo.dwo")
              DW_AT_comp_dir	("/home/pavel")
              DW_AT_GNU_pubnames	(true)
              DW_AT_GNU_dwo_id	(0x441cbc2aa7bff7c5)
              DW_AT_GNU_addr_base	(0x00000000)

If I run the same command from /tmp then I get the correct compilation directory, no matter which clang I use:

/tmp $ /tmp/clang.bad  -g -gsplit-dwarf  -c -o foo.o /tmp/foo.cpp 
/tmp $ llvm-dwarfdump foo.o 
foo.o:	file format ELF64-x86-64

.debug_info contents:
0x00000000: Compile Unit: length = 0x00000020 version = 0x0004 abbr_offset = 0x0000 addr_size = 0x08 (next unit at 0x00000024)

0x0000000b: DW_TAG_compile_unit
              DW_AT_stmt_list	(0x00000000)
              DW_AT_GNU_dwo_name	("foo.dwo")
              DW_AT_comp_dir	("/tmp")
              DW_AT_GNU_pubnames	(true)
              DW_AT_GNU_dwo_id	(0xfc9fc3a6ed2d6bbb)
              DW_AT_GNU_addr_base	(0x00000000)

Could you please check this out?

Thank you.

I believe I fixed this in r349065. (The DIFile used by the CU is special and distinct from the main source file. Its directory part specifies what becomes the DW_AT_comp_dir (the compilation directory), even if the source file was specified with an absolute path.)