[llvm-dev] yaml2obj support for COFF debug directories
Martin Storsjö via llvm-dev
llvm-dev at lists.llvm.org
Thu Mar 5 00:10:58 PST 2020
On Wed, 4 Mar 2020, Reid Kleckner via llvm-dev wrote:
> I think it seems like an oversight, and improvements in this area would be
> welcome.
> I think most of the effort in COFF <-> YAML translation has been for
> representing object files, and debug directories are a feature of fully
> linked PE images. With that in mind, it's not too surprising that the
> feature is missing.
In general, it should be possible to roundtrip linked PE images via yaml
just fine - their contents would just be part of the opaque section
contents blob. Hard to inspect and tweak by hand, but so are lots of other
things that are referended via data directories (like base relocation
tables) and stored in the plain section contents.
But debug directories have got one property which would break this - they
have a PointerToRawData field, that should contain the raw byte offset
within the linked PE image, to their content data. As roundtrip via yaml
does rewrite the file structure (and the output layout of yaml2obj isn't
supposed to be fixed), the exact value of this field would have to be
updated. As far as I know, yaml2obj doesn't do this at the moment.
llvm-objcopy's COFF backend does try to do it
(COFFWriter::patchDebugDirectory in
llvm/tools/llvm-objcopy/COFF/Writer.cpp), but when I now reread the code
there, I'm pretty sure I made some mistakes there. (I incorrectly assumed
that the raw data is interleaved after each debug directory header.) With
your lld patch for the CET compat flag, it should be easy to generate a
testcase for that, with more than one debug directory.
One general design question regarding this in obj2yaml, is that when the
debug directories are synthesized, should they be appended onto one of the
existing sections (with normal hex dumped contents) or created as an
entirely new section? Synthesizing them separately works fine for cases
where a file is generated entirely from scratch with yaml, but is tricky
for obj2yaml, where the original debug directories pretty much need to be
left in place. In that case, each time a PE image is roundtripped via
yaml, it would generate yet another set of debug directories, orphaning
the old ones.
Finally, when reading the spec, it also seems like the payload of a debug
directory doesn't even need to be in the mappable parts of sections, but
could be in unmapped areas of the PE image file (by having
AddressOfRawData set to zero, so it can only be found via
PointerToRawData). This doesn't seem like something that e.g.
llvm-readobj's --coff-debug-directoriy currently supports though (and
llvm-objcopy expects the paylaod to be moved along as part of sections'
contents).
I'll make a note to try to fix llvm-objcopy's assumptions about the
location of the payload this sometime in the future.
// Martin
More information about the llvm-dev
mailing list