[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