std library hooks

[Manu]

2012/4/15 "Jérôme M. Berger" <jeberger at free.fr>

> H. S. Teoh wrote:
> > I made a one-function library called mylib.a, that exports a single
> > function 'mylibfunc'. Then I wrote some code in aux.c that calls
> > 'mylibfunc', and then in main.c, I define a different version of
> > 'mylibfunc' along with main(). Here's the result of various orderings of
> > the linker command-line (each .c file is compiled with gcc -c
> > beforehand):
> >
> > 1) ld mylib.a aux.o main.o
> >       Works, main's version of 'mylibfunc' is picked up
> >
> > 2) ld aux.o mylib.a main.o
> >       Fails: ld complains that 'mylibfunc' is multiply defined
> >
> > 3) ld aux.o main.o mylib.a
> >       Works, main's version of 'mylibfunc' is picked up
> >
> > 4) ld main.o aux.o mylib.a
> >       Works, main's version of 'mylibfunc' is picked up
> >
> > So here's my understanding of what happens:
> >
> > For (1), ld doesn't even care about mylib.a because there are no
> > unresolved symbols to resolve yet. Then it sees aux.o, which has
> > unresolved reference to 'mylibfunc', then it sees main.o, which resolves
> > this symbol, so it finishes successfully.
> >
> > For (2), ld sees aux.o first, which has unresolved symbol 'mylibfunc',
> > so it searches mylib.a next, and finds 'mylibfunc' in mylib.a, so it
> > links that in. Now when it sees main.o next, it sees 'mylibfunc' again,
> > and complains that it's already been defined.
> >
> > For (3), ld sees aux.o first, which references unresolved symbol
> > 'mylibfunc', then it sees main.o, which defines 'mylibfunc', so now all
> > symbols are resolved. So when it sees mylib.a next, it does nothing 'cos
> > there are no more symbols to resolve. So this leaves us with main's
> > version of 'mylibfunc' linked.
> >
> > For (4), ld sees main.o first, which exports 'mylibfunc', so when it
> > sees aux.o next, which references 'mylibfunc', it resolves it to main's
> > version of 'mylibfunc'. Then it sees mylib.a but does nothing because
> > all symbols have already been resolved.
> >
> > Conclusion: defining your own version of library functions work... if
> > you link the library after your own version. If the library's version
> > gets picked up first, the linker will complain about duplicate symbols.
> >
>         In addition to what you have just said, there is another subtility.
> If either main.o or aux.o references another symbol mylibfunc2, and
> if both mylibfunc and mylibfunc2 are provided by the *same* object
> file inside mylib.a, then when the linker pulls in mylibfunc2 it
> will *also* pull in mylibfunc and complain about a duplicate
> definition. This also depends on your version of the compiler and
> linker, and on the compilation options (I believe the
> -ffunction-sections gcc option makes the issue disappear for example).
>
>                Jerome
> --
> mailto:jeberger at free.fr
> http://jeberger.free.fr
> Jabber: jeberger at jabber.fr
>
>
Wow. This all sounds... really unpredictable. I think I prefer the multiply
defined symbols complaint, then I know, and I can deal with it
appropriately. Having weird subtle rules to resolve this stuff seems far
too likely to go wrong/break in a way that may either be undetected, or the
programmer doesn't understand. :/ .. But fair enough.

How does weak linkage fit into this? If it finds a weak symbol while
scanning for an unresolved symbol, will it then continue scanning when it
finds the weak symbol, just in case there may be another strong one in
there somewhere?

But basically, in order to override druntime implementations of functions
in the way walter suggests, I need to carefully craft my linker commend
line, and it should be work as he says? (not clear whether I should link
the libs at the start or the end of the command line)
Perhaps it would be safer to use weak linkage for those functions in
druntime that one may want to override, and then document the possibility?
.. It feels somewhat like an exploit otherwise :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120415/8c29822a/attachment-0001.html>