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]

Re: gld not complaining about undefined symbols


All,

In hunting down this problem, I have placed the following piece of code
into my reloc howto. This
code is adapted from code in bfd_perform_relocation().

if (bfd_is_und_section (symbol->section))
 return bfd_reloc_undefined;

This catches undefined symbols so that no relocation occurs, and I get
error messages from ld as
expected.

Now then, the original code in bfd_perform_relocation() looks like:

if (bfd_is_und_section (symbol->section))
  && (symbol->flags & BSF_WEAK) == 0
  && output_bfd == (bfd *) NULL)
  return bfd_reloc_undefined;

The above code happens right before the call to the howto. Since this
code does not catch the
undefined symbol, does this mean that my GAS is flagging symbols as
weak? If so, how does this
happen, as I am not doing this intentionally.

Regards,
Eric


Eric DeVolder wrote:

> 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]