[PATCH] D56584: [llvm-objcopy] [COFF] Fix writing object files without symbols/string table

Martin Storsjö via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 11 03:29:16 PST 2019


mstorsjo added a comment.

In D56584#1353961 <https://reviews.llvm.org/D56584#1353961>, @jhenderson wrote:

> In D56584#1353933 <https://reviews.llvm.org/D56584#1353933>, @mstorsjo wrote:
>
> > In D56584#1353916 <https://reviews.llvm.org/D56584#1353916>, @jhenderson wrote:
> >
> > > I'm not quite sure I follow why this only affects executable files? Why is this an issue in PE but not plain COFF?
> >
> >
> > Initially I tried to make the output of llvm-objcopy as close as possible to the output from various tools (llvm-mc and MSVC), and to achieve this, I only skipped including the symbol/string table in executables, while keeping it present in object files.
> >
> > I know that exactly matching the output of another tool shouldn't be a goal in itself, but I don't know if there are tools out there that would flat out reject an object file with an omitted symbol/string table, as opposed to an empty symbol/string table. So keeping this distinction probably is safer.
>
>
> So the behaviour change is that for objects, the object now has a pointer to the symbol table, which it didn't before. I think I get it now. The problem is the writeSymbolStringTables function, and you want that to always write a size for object files, even if the table is empty, right?


Correct. Previously the pointer to the symbol table was zero, so the string table length (which follows directly after the symbol table) was written at offset 0 in the file, clobbering the header.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56584/new/

https://reviews.llvm.org/D56584





More information about the llvm-commits mailing list