ld can leave undefined symbols in non-relocatable output

ld can leave undefined symbols in non-relocatable output

[Joshua Oreman]

Hi everyone,

I'm on x86_64 using binutils 2.18.0 on GNU/Linux. I've recently run
across some counterintuitive behavior in the linker, but I'm not sure
whether it's intended or not. I was hoping someone on this list might
be able to clarify whether this is intended and dependable behavior,
or a bug.

% cat test.s
        .section .text
        .globl  _start
        .extern asym

        .equ    __need_asym, asym

_start:
        ret

% as -o test.o test.s
% ld -o test test.o
% nm test
0000000000600079 A __bss_start
0000000000600079 A _edata
0000000000600080 A _end
0000000000400078 T _start
                U asym

As you can see, the reference to "asym" remains undefined in the
output executable.

The use of an .equ statement to create undefined symbol references
originated in a need to "pull in" object files from an archive due to
configuration options, and it works well for that task. It has the
benefit of not increasing the output size, which is important in the
environment it's used in (the network boot ROM gPXE). However, I would
have expected the link to fail if the referenced symbol is not
available (as in this test case), and it does not. Any clarification
would be greatly appreciated.

Thank you,

-- Josh

Re: ld can leave undefined symbols in non-relocatable output

[Dave Korn]

Joshua Oreman wrote:
> Hi everyone,
> 
> I'm on x86_64 using binutils 2.18.0 on GNU/Linux. I've recently run
> across some counterintuitive behavior in the linker, but I'm not sure
> whether it's intended or not. I was hoping someone on this list might
> be able to clarify whether this is intended and dependable behavior,
> or a bug.

  This is completely as intended and by design.  You can leave undefined
references in ELF executables (both SO libs and applications) and they are
filled in by the dynamic loader at runtime.  Therefore it is not seen as an
error at link-time if the definition is not available then; it may be supplied
by a library that is only available then.

    cheers,
      DaveK

Re: ld can leave undefined symbols in non-relocatable output

[Dave Korn]

Dave Korn wrote:
> Joshua Oreman wrote:
>> Hi everyone,
>>
>> I'm on x86_64 using binutils 2.18.0 on GNU/Linux. I've recently run
>> across some counterintuitive behavior in the linker, but I'm not sure
>> whether it's intended or not. I was hoping someone on this list might
>> be able to clarify whether this is intended and dependable behavior,
>> or a bug.
> 
>   This is completely as intended and by design.  You can leave undefined
> references in ELF executables (both SO libs and applications) and they are
> filled in by the dynamic loader at runtime.  Therefore it is not seen as an
> error at link-time if the definition is not available then; it may be supplied
> by a library that is only available then.

  PS: See also the documentation for the "--no-undefined" option in the LD
man/info page.

    cheers,
      DaveK

Re: ld can leave undefined symbols in non-relocatable output

[Joshua Oreman]

[-- Attachment #1: Type: text/plain, Size: 1726 bytes --]

On Tue, 2009-08-04 at 11:41 +0100, Dave Korn wrote:
> Dave Korn wrote:
> > Joshua Oreman wrote:
> >> Hi everyone,
> >>
> >> I'm on x86_64 using binutils 2.18.0 on GNU/Linux. I've recently run
> >> across some counterintuitive behavior in the linker, but I'm not sure
> >> whether it's intended or not. I was hoping someone on this list might
> >> be able to clarify whether this is intended and dependable behavior,
> >> or a bug.
> > 
> >   This is completely as intended and by design.  You can leave undefined
> > references in ELF executables (both SO libs and applications) and they are
> > filled in by the dynamic loader at runtime.  Therefore it is not seen as an
> > error at link-time if the definition is not available then; it may be supplied
> > by a library that is only available then.
> 
>   PS: See also the documentation for the "--no-undefined" option in the LD
> man/info page.

I did read all of that, and I'd like to clarify that I'm building a
statically linked executable, and "normal" undefined symbol references
(e.g. calling an undefined function) cause errors. It's just this
special type of reference with an unused .equ that puts an undefined
symbol entry into the symbol table without causing the link to fail.

I believe the difference may lie in the fact that the unused .equ does
not have any relocations that reference the undefined symbol, so there
is no impediment to proper execution of the code. It seems that the
static linker decides whether an undefined symbol "matters" based on its
impact, in terms of relocations that reference it, rather than its
simple existence. Is this accurate?

Thanks, and sorry if these are novice questions,

-- Josh


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ld can leave undefined symbols in non-relocatable output

[Dave Korn]

Joshua Oreman wrote:

> I did read all of that, and I'd like to clarify that I'm building a
> statically linked executable, and "normal" undefined symbol references
> (e.g. calling an undefined function) cause errors. It's just this
> special type of reference with an unused .equ that puts an undefined
> symbol entry into the symbol table without causing the link to fail.
> 
> I believe the difference may lie in the fact that the unused .equ does
> not have any relocations that reference the undefined symbol, so there
> is no impediment to proper execution of the code. It seems that the
> static linker decides whether an undefined symbol "matters" based on its
> impact, in terms of relocations that reference it, rather than its
> simple existence. Is this accurate?

  Yes, that's basically it.  As a consequence of there not being any relocs, it
seems that the --no-undefined option doesn't actually complain either - I'm not
sure if that's by design or not, but as you say, a symbol that just sits there
in the symbol table and has no relocs against it is no harm; it just continues
being undefined, so LD has no reason to forbid it in general - even a
statically-linked application might dlopen() something at runtime, after all.

    cheers,
      DaveK