[PATCH] D38513: [LLD] [RFC] [COFF] Add support for GNU binutils import libraries

[Shoaib Meenai via Phabricator via llvm-commits]

smeenai added a comment.

In https://reviews.llvm.org/D38513#896150, @mstorsjo wrote:

> In https://reviews.llvm.org/D38513#896073, @smeenai wrote:
>
> > My hypothesis is that link might special-case zero-sized sections, but I have no evidence to back that up yet.
>
>
> I don't think that's it. Consider linking two separate GNU import libraries in the same module; if just piling up section chunks into `.idata$5` as they are referenced, you'd have an IAT with entries mixed from both. So some sort of grouping per import library is needed, but the exact conditions for it aren't really known. Perhaps only ordering `.idata$*` chunks like this, but not other ones?


You're right; there appears to be no special-casing for zero-sized sections in general.

I don't think it's a library ordering thing either though. I extracted the individual object files out of the import library and linked against those rather the import library (in the order in which they would have been referenced, i.e. the object file containing the func entry was before the object file containing the zero byte section), and the imports of the linked image were still correct.

In general, link.exe is definitely doing some special-casing for `.idata$*` chunks though:

- They end up in the `.rdata` section in the final image (whereas LLD produces a separate `.idata` output section).
- The import address table chunks (`.idata$5`) end up at the start of the `.rdata` section, so regular grouping order isn't respected there.


https://reviews.llvm.org/D38513