Paul Pluzhnikov <[EMAIL PROTECTED]> wrote: > 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).
Oh,m thanks for that detailed examination. I would not even have known what to look for. > 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. Hm. Yes. I see this is an important usecase. But having 'self contained modules' with symbols not interfering with each other (except when explicitly told so) seems o be an interesting use case as well. > 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, That's why I initially stumbled over it (porting from Windows...) > 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). I thought the reason for that was that each DLL uses its own heap, so malloc() in one and free() in another is problematic as they access different heaps. But I think I see the issues are related. Again, thanks for the expllanation. Andre' _______________________________________________ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
