This is an archive of the discontinued LLVM Phabricator instance.

[ELF] - Use information available from DW_AT_comp_dir attribute when doing error reporting.
AbandonedPublic

Authored by grimar on Dec 24 2016, 7:42 AM.

Details

Summary

Imagine we call clang -g aaa/bbb.cpp. Current error reporting would
print something like:

error: aaa/bbb.cpp :x: error text.

But we are able to print full path including current working directory of a compilation command,
like:

/home/bar/some_path/aaa/bbb.cpp:1: text

We can get this information from DW_AT_comp_dir attribute which is:
"A DW_AT_comp_dir attribute whose value is a null-terminated string containing the current
working directory of the compilation command that produced this compilation unit in
whatever form makes sense for the host system."

Idea of doing that change belongs to Eugene Leviant, thanks again !

Diff Detail

Event Timeline

grimar updated this revision to Diff 82444.Dec 24 2016, 7:42 AM
grimar retitled this revision from to [ELF] - Use information available from DW_AT_comp_dir attribute when doing error reporting..
grimar updated this object.
grimar added reviewers: ruiu, rafael, evgeny777, davide.
grimar updated this object.
grimar added subscribers: llvm-commits, grimar.
evgeny777 added inline comments.Dec 25 2016, 8:47 AM
ELF/InputFiles.cpp
74

Do we have a unit tests for zero number of CU ?

davide added inline comments.Dec 25 2016, 9:29 AM
ELF/InputFiles.cpp
48–50

you can probably simplify a bit using the ternary operator here, i.e.

auto &patatino = static_cast<...>(Sec);
return (patatino.getFlags() & SHF_ALLOC) ? patatino.getOffset(); 0;
ELF/InputFiles.h
204–206

what do you mean with "compilation command" ?

test/ELF/conflict2.s
10

s/Assembler file/The file/
s/following/the following/

11

/home/bar/some_path clang ?

13

s/linker/the linker/

14

full patch or full path?

grimar updated this revision to Diff 82525.Dec 27 2016, 12:06 AM
  • Addressed review comments.
ELF/InputFiles.cpp
48–50

Done.

74

Example of test which does not have CUs but has debug line table is conflict.s:

  1. RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %p/Inputs/conflict-debug.s -o %t-dbg.o
  2. RUN: not ld.lld %t-dbg.o %t-dbg.o -o %t-dbg 2>&1 | FileCheck -check-prefix=DBGINFO %s

Where conflict-debug.s is:

.file 1 "conflict-debug.s"
.globl zed
.loc 1 4
zed:
  nop
ELF/InputFiles.h
204–206

umb@ubuntu:~/tests/181$ clang 111/1.cpp -g -o out

here I mean "clang 111/1.cpp -g -o out" is a compilation command.

I based on termonology from DW_AT_comp_dir description:

A DW_AT_comp_dir attribute whose value is a null-terminated string containing the current
working directory of the compilation command that produced this compilation unit

May be change it to next ?

// Containing the compilation directory for CU.

test/ELF/conflict2.s
10

Done.

11

I meant that foo/1.cpp is placed in
/home/bar/some_path which is working dirrectory for a call, like:

bar@ubuntu:~/some_path$ clang foo/1.cpp -g -S -o asm.s

Updated the comment.

13

Done.

14

Fixed.

ruiu added inline comments.Jan 3 2017, 3:45 PM
ELF/InputFiles.cpp
57

This function does more than its name says -- you are now initializing not only DwarfLine but CompilationDir. You probably should save Dwarf instead of DwarfLine and CompilationDir.

grimar added inline comments.Jan 9 2017, 5:53 AM
ELF/InputFiles.cpp
57

There is a problem with saving just DWARFContextInMemory (Dwarf).
LLVM DWARF parsers currently wants to see CU as argument for parsing LineTable:
Example:

  DWARFCompileUnit *CU = getCompileUnitForAddress(Address);
  if (!CU)
    return Result;
...
    if (const DWARFLineTable *LineTable = getLineTableForUnit(CU))

CU are taken from .debug_info section. Our LLD implementation works differently,
allowing us to show location for objects like undef-debug.s, that does not have .debug_info:

.file 1 "dir/undef-debug.s"
.loc 1 3
        .quad zed3
...

As far I know our current logic consistent with gold/bfd, which afaik can live without .debug_info, like we do.

At the same time, DWARF Debugging Information Format, Version 4 says:

"Line number information generated for a compilation unit is represented in the .debug_line
section of an object file and is referenced by a corresponding compilation unit debugging
information entry (see Section 3.1.1) in the .debug_info section."

For each compilation unit compiled with a DWARF producer, a contribution is made to the
.debug_info section of the object file.

What makes me wonder if it is correct to work with .debug_line when there is not .debug_info section
and so no info about CUs.

So there seems to be 2 ways:

  1. Store both DwarfLine and CompilationDir like now. That way we still have extended messages for case when there is no .debug_section,

though it is not clear for me if we really should care about that cases. It seems our testcases are a bit too synthetic, looks there
should not be real producer that emits .debug_line without .debug_info ?

  1. Store only Dwarf (DWARFContextInMemory) and ignore cases when object has no .debug_info section. That probably can simplifiy implementation.

Looks we can go with 2 ?

grimar abandoned this revision.Mar 30 2017, 1:31 AM