Andre Poenitz <[EMAIL PROTECTED]> writes: > Is there a possibility to 'relink' an existing library such that the > result of this operaton would be the same as if -Bsymbolic had been > given at link time?
No. First, the DSO result of a link is considered "final", further modification is difficult if not impossible. Second, '-Bsymbolic' doesn't just set DT_SYMBOLIC tag (which I initially thought was all it did). It also changes the way that intra-library calls are performed (directly, rather then through PLT). If you only had one "problem" symbol, you could binary-edit the DSO (as in emacs hexl-mode), and "retarget" all calls to "[EMAIL PROTECTED]" to go directly to "problemSymbol" instead by patching its address into the call instruction. Since all direct calls on x86 are PC-relative, you'd have to compute offset separately for each call, so this is more tedious if problemSymbol is called a lot. Another alternative is to perform equivalent patch at runtime: find the GOT for the problemSymbol, and simply put correct address in there. This requires understanding of ELF image in memory and the process of lazy resolution, but isn't too difficult. > [Btw, am I the only one thinking that using '-Bsymbolic' should rather > be the common case instead of the exception?] Initially, the motivation for current behaviour was to emulate what users came to expect with archive libraries: if you wanted myfprintf.o to be used, you simply linked that before libc.a, and magically all calls to fprintf() went your way. This would have been broken if printf() [which you didn't replace] called libc.so`fprintf() directly (instead of through PLT), as would happen with -Bsymbolic. Another thing that would break if -Bsymbolic was the default, is LD_PRELOAD, which is often very useful for e.g. debug malloc. AIX is the only UNIX I know where (effectively) -Bsymbolic is the default, and they had to do special hack to allow for user-replaceable malloc. Good luck intercepting/redirecting any other libc functions. In fact, their linking model caused so many problems with porting, that they recently introduced "deferred linking", which effectively restores the shared library behaviour to that of all other UNIXes. Win32 also effectively uses the same model, resulting in a whole slew of complications, such as: you shalt not free() memory in FOO.DLL, if that memory was malloc()ed in BAR.DLL (unless both were linked with /MD flag). Cheers, -- In order to understand recursion you must first understand recursion. Remove /-nsp/ for email. _______________________________________________ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
