Re: Minimal program crashes, depending on linker script

[Andre Poenitz]

Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> wrote:
> Andre Poenitz <poenitz@htwm.de> 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
> "problemSymbol@plt" 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'