[llvm-bugs] [Bug 36793] New: Don't assume we only have one CU when parsing .debug_line

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36793

            Bug ID: 36793
           Summary: Don't assume we only have one CU when parsing
                    .debug_line
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: ELF
          Assignee: unassignedbugs at nondot.org
          Reporter: jh7370.2008 at my.bristol.ac.uk
                CC: llvm-bugs at lists.llvm.org

In LLD, we currently parse the .debug_line section in an object file to emit
source information when we can for undefined symbol errors. The code currently
assumes that there is only a single CU in the object file, and therefore that
the offset of the line table corresponding to that CU is always zero. This
isn't always true. I can think of at least three different cases for this
situation:

1) Objects built by combining multiple objects in a -r link.
2) Objects made via LTO.
3) Objects built from hand-written assembly.

We can probably ignore 3), but 1) and 2) are more important, and can result in
undefined symbol errors being reported with missing line information:

// test.c
int foobar();

int _start()
{
    return foobar();
}

// test2.c
int baz();

int foobar()
{
    return baz();
}

C:\Work> clang.exe -target x86_64-pc-linux -c test.c test2.c -g
C:\Work> ld.lld.exe test.o test2.o -o test.ro -r
C:\Work> ld.lld.exe test2.o test.o -o test2.ro -r

C:\Work> ld.lld.exe test.ro -o test.elf
C:\Work\ld.lld.exe: error: undefined symbol: baz
>>> referenced by test.ro:(foobar)

C:\Work> ld.lld.exe test2.ro -o test.elf
C:\Work\ld.lld.exe: error: undefined symbol: baz
>>> referenced by test2.c:5
>>>               test2.ro:(foobar)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180319/c8266e83/attachment.html>