This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

gld not complaining about undefined symbols


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
/*
 * File:		app.ld
 * Purpose:		GNU ld script for testing
 *
 * Notes:		This scripts needs all files compiled with the
 *				following gcc options:
 *
 *				In addition, the -G 0 option must also be
 *				passed to ld.
 *
 * Author:		Eric DeVolder
 * Date:
 *
 * Modifications:
 *
 */

/*
OUTPUT_FORMAT("elf64-e3", "elf64-e3", "elf64-e3")
OUTPUT_ARCH(e3)

ENTRY(main)
*/

MEMORY
{
	ram	: org = 0x00100000, len = 0x00800000
}

SECTIONS
{
	.text	:
	{
		*(.text)
		*(.rodata)
	} > ram

	.debug (NOLOAD) :
	{
		. = . + 0x00000400;
	} > ram

	.data	:
	{
		*(.data)
		*(.got)						/* to make the linker happy */
	} > ram

	.bss (NOLOAD)	:
	{
		*(.bss)
		*(COMMON)
	} > ram

	/*
	 * The .sdata and .sdata2 sections are provided below solely
	 * for the purpose of making the GNU linker happy. They should
	 * NOT contain any items whatsoever. You should verify this.
	 */
	.sdata (NOLOAD)		:
	{
		*(.sdata)
		*(.sbss)
	} > ram

	.sdata2 (NOLOAD)	:
	{
		*(.sdata2)
		*(.sbss2)
	} > ram

	/DISCARD/ :
	{
		*(*)
	}
}


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]