[PATCH] D143540: [llvm-lib] Add support for writing COFF archives.

Martin Storsjö via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 9 00:01:11 PST 2023


mstorsjo added a comment.

In D143540#4114098 <https://reviews.llvm.org/D143540#4114098>, @jacek wrote:

> In D143540#4113923 <https://reviews.llvm.org/D143540#4113923>, @mstorsjo wrote:
>
>> So - I'm not very familiar with the internals of static archives, can you elaborate a bit more on what `K_COFF` vs `K_GNU` means here. Is this a format flag which is written to the static archives themselves (I believe not?), or just different conventions for what details are written and found in the archives?
>
> It's about how details are written to the archives, the meaning in this patch it analogical to how reader uses them, see Archive class constructor. Essentially, if the second member is another symbol table, then the archive treated as `K_COFF`. The other subtle difference is that strings in string table are null-terminated, see `ArchiveMemberHeader::getName`. This patch makes it possible to write archives that will be recognized as `K_COFF`.

Ok, thanks for the explanation! (So far in my endeavours, I've diven into most of the internals of PE/COFF, but never had to worry about the details of static archives.)

>> If I read the patch correctly (I just eyed it quickly) - `llvm-ar` will continue to write things like it used to, while `llvm-lib` will pick `K_COFF` (unless it's a thin library)?
>
> Yes, nothing changes for llvm-ar yet. I guess it would make sense to add new llvm-ar --format argument for that, but we probably shouldn't change the default. If we changed the default for Windows host, it would require explicit --format when cross compiling from Windows, which is currently not required.

Yeah we shouldn't make such differences based on the host where the tool is running. There's some predecent for autodetecting the mode based on other context (preexisting archive or archive members, or maybe also objects passed on the command line), which mostly should avoid the cross compilation issues. See https://github.com/llvm/llvm-project/commit/a0d42c86dbcb150c2a7a3d8f2a8500dcfb98a5d1 for the original implementation of that (I believe it has evolved a bit still through the years since).



================
Comment at: llvm/test/tools/llvm-lib/duplicate.test:20
+RUN: cd %t && llvm-lib -out:foo.lib foo.o foo.o abc.o bar.o  foo.o foo.o
+RUN: llvm-nm --print-armap %t/foo.lib | FileCheck %s --check-prefix=DUP
+# DUP: Archive map
----------------
jacek wrote:
> mstorsjo wrote:
> > Before this change, would `--print-armap` not have printed anything at all, or what's the change in externally visible functionality here?
> Without this patch, it would print duplicated and unsorted symbols:
> ```
> Archive map
> b in bar.o
> c in abc.o
> a in abc.o
> b in abc.o
> a in foo.o
> ```
I see, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143540



More information about the llvm-commits mailing list