Home Original page

COFF vs ELF handling of undefined symbols

Jan Beulich jbeulich@suse.com
Fri Jun 27 10:06:25 GMT 2025 
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
More information about the Binutils mailing list