Home Original page

gld not complaining about undefined symbols

Eric DeVolder devolder@evsx.com
Thu Jan 6 13:06:00 GMT 2000 
All,

I've created a new target cpu arch for binutils and have the entire
binutils up and running. However, when I link object files together with
ld, it does not complain in the least about undefined symbols. For
example, I've got a small test program that calls memcpy(). At some
point, I'll actually have a library with memcpy() in it, but for now, I
would expect ld to issue an error since memcpy() can not be resolved.
Instead, it quite happily creates the [linked] output file a.out.

Here's what I've discovered thus far:

- running objdump -d -r on the object files I see the relocs for the
symbol references, and they do look correct
- running objdump -d -r on the [linked] output file a.out, there are no
relocs, and insn fields have what appears to be junk values in them (as
opposed to zero).
- running nm on the [linked] output file a.out, there are Undefined
symbols.
- providing the linker script below does not change the behavior any.

I thought that the reloc howto functions were only called when symbol
value had been resolved, else ld spits out an undefined symbol message.
Thus seeing garbage values in the insn fields confuses me because that
suggests the reloc howto has been invoked for an unresolved symbol.

I've briefly tested cross-hosted ppc and m68k GNU lds and they do issue
the error messages, as expected. So I'm pretty sure it is something I
did or can control. At one point in time, my ld did issue error
messages.

I'm not passing any parameters to ld other than the object files, so
perhaps there is some default setting for ld that is causing this
behavior? I have not yet had to modify any code in the binutils/ld
directory. I'm using ELF64. There is no GCC for this target
installed...yet.

I'm confused, thus I seek your collective wisdom.

Regards,
Eric
More information about the Binutils mailing list