Add a weak definition of mep_di to MeP's libgloss
Wed Feb 4 17:12:00 GMT 2009
[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