COFF vs ELF handling of undefined symbols

[Paul Edwards]

Hi Jan.

I passed your message on to the authors of pdld and slink
(both of which are now capable of producing libraries that
Microsoft's linker will accept - after a lot of effort, emails
and debate), and the author (Robert Pengelly) of slink
replied with the below. I'm not close to the issue myself, so
I'm not claiming to understand/agree (or disagree) with it,
nor the original issue - I'm merely passing it back in case
it is useful.



> Does anyone have knowledge or pointers that could help address the question
> of how we _should_ behave?

Unless there's a standard that I'm unware of then it should be up to
the developer and not any signel person.  If there developer wants to
only search referenced symbols then they should be allowed to and
people should just adapt to it (e.g. Using another flag like in the
case of pdld).  In slink I just create a link compatible library if
creating a PE/COFF library and again that's my choice.

> Therefore, if we deemed resolution of undefined symbols to be wrong for the COFF
> world

Again, like I said it's not a COFF problem it's a PE/COFF problem
cause it's Microsoft's implementations that cause issues.  COFF and
PE/COFF are two different things as Microsoft added a bunch of stuff
and made up there own rules about stuff regarding.  We can't say that
COFF in gernal is wrong as it worked fine in the Unix world until ELF
was created to address some of the sort fails with COFF (e.g.
Supporting different endianess).

That's my take on it but of course your perfectly entitled to have
your own views/opinions but like I said unless there actually is a
standard then I think no-one should be forced into one way or another
just because a few people think something.  In fact we've had the same
conversation about COFF vs PE/COFF, I wanted (pdld author) to
distinguish between the two but he wont and that's his choice.



On Fri, Jun 27, 2025 at 8:06 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> Hello,
>
> in the context of an inquiry regarding import library handling in the
> PE/COFF world [1], I came to notice a discrepancy in how undefined symbols
> are handled by GNU ld (presumably originally based on how ELF wants things
> handled) vs the Microsoft link.exe. GNU ld complains about undefined symbols
> only when they're actually referenced by a relocation. This is, aiui, the
> behavior expected in the ELF world, even if the ELF spec doesn't say so
> explicitly (according to my reading of it). MS link, otoh, complains about
> the mere presence of undefined symbols in some object's symbol table. Sadly
> the MS PE/COFF doc I have to hand (version 8.2) doesn't appear to say
> anything about how symbol / reloc resolution is supposed  to be handled.
> Hence link's behavior is all I have a reference in the MS PE/COFF world.
>
> There being multiple COFF flavors doesn't make things easier. It may well
> be that MS treats things differently from how COFF is being dealt with
> elsewhere.
>
> Does anyone have knowledge or pointers that could help address the question
> of how we _should_ behave?
>
> For context: Trying to make at least some progress towards addressing
> Paul's request, I found that libbfd's ILF handling (in peicode.h) actually
> creates an undefined symbol table entry for __IMPORT_DESCRIPTOR_<dllname>.
> Exactly like pre-ILF "real" import objects would have had it. Just that
> the symbol alone has no effect alone, as no relocation uses it. Therefore,
> if we deemed resolution of undefined symbols to be wrong for the COFF
> world, fixing that would apparently also address Paul's request. Whereas if
> we deemed present behavior okay, we'd need to introduce a fake relocation
> (COFF in principle and in general has such) that references said symbol,
> but otherwise does nothing.
>
> As to "in principle and in general": All architectures for which I'm
> aware of their relocation numbers (that is, in the PE/COFF world) have an
> "absolute" relocation (number 0), which does nothing. In libbfd, however,
> in most cases that relocation type isn't being spelled out in
> coff-<arch>.c. We'd need to add it, but the "different COFF flavors" may be
> getting in the way there. Plus, having tried it with a Cygwin linker, ld
> complains about such with "error: 0-bit reloc in dll". IOW quite a bit of
> prereq work would be needed if we had to go the "fake relocation" route.
>
> Jan
>
> [1] https://sourceware.org/pipermail/binutils/2025-May/140858.html