This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Add a weak definition of mep_di to MeP's libgloss


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.


Cheers
  Nick


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