Add a weak definition of mep_di to MeP's libgloss

Nick Clifton
Wed Feb 4 17:12:00 GMT 2009

Hi Konrad,

   [DJ has replied to me off list pointing out that I was using a 
non-official set of gcc sources to trigger this problem, so I have 
withdrawn my patch.  Still the issue of using weak stub functions 
remains so ...]

>>> If you wish to override the definition of a symbol, add an object
>>> [...] defining that symbol before the library containing the
 >>> overridden definition.

>> The problem with this solution is that it requires a specific link 
>> order.  I cannot guarantee that the user will specify the 
>> libraries and object files in the correct order on the linker 
>> command line to achieve this effect.

> I don't use newlib at the moment, but: normally, when invoking the
> linker through the compiler driver, the C library and other internal
> libraries, such as libgloss.a should be added to the end of the user's
> command line automatically.
> Furthermore, I'm not sure that weak does the right thing: if the
> non-weak definition happens to be in an archive *behind* newlib (or
> libgloss), and the symbol has already been resolved by the weak
> definition in newlib, will the member containing the non-weak definition
> be extracted?

Yes.  Or at least it should.  A non-weak definition should always 
override a weak definition, even if the non-weak definition is supplied 
in an archive and not an object file.

The sceanario where a non-weak symbol will fail to override a weak 
symbol is if the non-weak version is in an archive which is on the 
linker command line *before* the object file that references it and the 
weak version is in an object file or archive after the reference.  This 
is not really significant however since the same weakness applies to the 
technique of providing the symbol as a separate object file in an archive.

> All these complications are avoided if "fall-back" definitions are put
> into individual .o files.  This is completely independent of whether to
> mark the definition weak or not.

Agreed.  I was just being lazy by not putting the stub symbol into a 
separate source file for compilation into the libgloss library.  Making 
the symbol weak is still a good idea in my opinion though.  It allows a 
"proper" definition of the symbol to be provided by an object file or 
archive specified later on the linker command line without triggering 
any complaints about multiply defined symbols.

> Newlib is a _library_.  By definition, it is used in projects we have
> absolutely no knowledge about.  Who are we to decide whether the size of
> the final executable is a real concern or not?

Not us.  But users who are concerned about the size of executables (and 
shared libraries) ought to be aware of the various compile-time and 
link-time techniques for reducing the size of binaries.  Still I agree 
that making their problems worse by not separating out potentially 
unneeded code and symbols into separate object files is a bad idea.


More information about the Newlib mailing list