<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 - llvm-objcopy generates unhelpful PE/COFF debug data for gnu-debuglink"
href="https://bugs.llvm.org/show_bug.cgi?id=45277">45277</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>llvm-objcopy generates unhelpful PE/COFF debug data for gnu-debuglink
</td>
</tr>
<tr>
<th>Product</th>
<td>tools
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>llvm-objcopy/strip
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>vit9696@avp.su
</td>
</tr>
<tr>
<th>CC</th>
<td>alexander.v.shaposhnikov@gmail.com, jake.h.ehrlich@gmail.com, jh7370.2008@my.bristol.ac.uk, llvm-bugs@lists.llvm.org, rupprecht@google.com
</td>
</tr></table>
<p>
<div>
<pre>After stripping DWARF debug information one can use --add-gnu-debuglink to link
the resulting file with the original file containing the debug information:
$ cp file.dll file.debug
$ llvm-objcopy --strip-unneeded file.dll
$ llvm-objcopy --add-gnu-debuglink=$(pwd)/file.debug file.dll
When working with PE/COFF files this functionality is unfortunately very
limited:
<a href="https://github.com/llvm/llvm-project/blob/f69eba07726a9fe084812aa224309d62c4bdd2e4/llvm/tools/llvm-objcopy/COFF/COFFObjcopy.cpp#L84-L90">https://github.com/llvm/llvm-project/blob/f69eba07726a9fe084812aa224309d62c4bdd2e4/llvm/tools/llvm-objcopy/COFF/COFFObjcopy.cpp#L84-L90</a>
1. Unlike ELF, which gets a section with .gnu_debuglink name, PE/COFF files get
anonymous sections like /1234. This makes it very hard to reliably locate the
section, as it does not even have a magic, just a filename and a CRC32 hash.
.gnu_debuglink is 14 bytes long, while PE/COFF has 8 bytes maximum for the
section name. However, even if we cannot use this name, any other unique value
will work just fine (e.g. .dbglink or .debug).
2. .gnu_debuglink section is not an expected way to link PE with the debug
information. In general for PE/COFF a CodeView entry in debug DataDirectory is
used in either PDB 2.0 (NB10) or PDB 7.0 (RSDS) format.
For DWARF this is not added by llvm-objcopy, but it is likely desired, as
several tools for e.g. UEFI firmware debugging rely on at least some kind of
CodeView entry to be present.
In MinGW mode LLD already generates a dummy PDB 7.0 entry:
<a href="https://github.com/llvm/llvm-project/blob/8620bb9534342176ac739e2a587e4cecf437310c/lld/COFF/Writer.cpp#L1823-L1831">https://github.com/llvm/llvm-project/blob/8620bb9534342176ac739e2a587e4cecf437310c/lld/COFF/Writer.cpp#L1823-L1831</a>
For non-LLVM projects, such as EDK II GenFw utility used for building UEFI
firmware PE files from ELFs, it is common to add a PDB 2.0 (NB10) entry:
<a href="https://github.com/tianocore/edk2/blob/b219e2c/MdePkg/Include/IndustryStandard/PeImage.h#L614">https://github.com/tianocore/edk2/blob/b219e2c/MdePkg/Include/IndustryStandard/PeImage.h#L614</a>
Perhaps, this can be adopted in llvm-objcopy as well.
3. Tools like GenFw also embed full file path instead of just the base name,
which makes it much easier to locate the file on the host during the debugging
session.
I believe GNU objcopy for ELF also strips the path, but for convenience reasons
we can make an option to keep it. E.g.
--add-gnu-debuglink=/path/to/filename,/path/to/embedded/filename.</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>