This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: gld not complaining about undefined symbols
- To: devolder at evsx dot com
- Subject: Re: gld not complaining about undefined symbols
- From: Ian Lance Taylor <ian at zembu dot com>
- Date: 6 Jan 2000 17:21:26 -0500
- CC: binutils at sourceware dot cygnus dot com
- References: <3875054A.71ACD806@evsx.com> <38751616.4F2C4AD5@evsx.com>
Date: Thu, 06 Jan 2000 16:24:22 -0600
From: Eric DeVolder <devolder@evsx.com>
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.
I don't see any such code in bfd_perform_relocation. The code I see
looks like this:
/* If we are not producing relocateable output, return an error if
the symbol is not defined. An undefined weak symbol is
considered to have a value of zero (SVR4 ABI, p. 4-27). */
if (bfd_is_und_section (symbol->section)
&& (symbol->flags & BSF_WEAK) == 0
&& output_bfd == (bfd *) NULL)
flag = bfd_reloc_undefined;
Then the variable flag becomes the return value if nothing else
unusual happens.
In your case, it sounds like a howto function is being called, and
that howto function is returning something other than
bfd_reloc_continue, so whatever it returns becomes the return value
from bfd_perform_relocation.
What sources are you looking at?
Ian