<html>
    <head>
      <base href="https://bugs.llvm.org/">
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Don't assume we only have one CU when parsing .debug_line"
   href="https://bugs.llvm.org/show_bug.cgi?id=36793">36793</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>Don't assume we only have one CU when parsing .debug_line
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>lld
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>unspecified
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>PC
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>Windows NT
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>normal
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>ELF
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>unassignedbugs@nondot.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>jh7370.2008@my.bristol.ac.uk
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>llvm-bugs@lists.llvm.org
          </td>
        </tr></table>
      <p>
        <div>
        <pre>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
<span class="quote">>>> referenced by test.ro:(foobar)</span >

C:\Work> ld.lld.exe test2.ro -o test.elf
C:\Work\ld.lld.exe: error: undefined symbol: baz
<span class="quote">>>> referenced by test2.c:5
>>>               test2.ro:(foobar)</span ></pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>