Re: PATCH: Handle DF_1_INTERPOSE

["H. J. Lu" <hjl at lucon dot org>]

On Sat, May 31, 2003 at 10:52:41PM -0700, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> H. J. Lu wrote:
> 
> > With DF_1_INTERPOSE, it be changed to
> > 
> > 	call libc version
> 
> That's nonsense, we have no direct function calls.  All is done via
> function pointers.

This is what pthread_self looks like

0x411037b0 <pthread_self+0>:    push   %ebp
0x411037b1 <pthread_self+1>:    mov    %esp,%ebp
0x411037b3 <pthread_self+3>:    sub    $0x8,%esp
0x411037b6 <pthread_self+6>:    mov    %ebx,0xfffffffc(%ebp)
0x411037b9 <pthread_self+9>:    xor    %eax,%eax
0x411037bb <pthread_self+11>:   call   0x4102d4ed <__i686.get_pc_thunk.bx>
0x411037c0 <pthread_self+16>:   add    $0x46254,%ebx
0x411037c6 <pthread_self+22>:   mov    0x23b0(%ebx),%edx
0x411037cc <pthread_self+28>:   test   %edx,%edx
0x411037ce <pthread_self+30>:   jne    0x411037d7 <pthread_self+39>
0x411037d0 <pthread_self+32>:   mov    0xfffffffc(%ebp),%ebx
0x411037d3 <pthread_self+35>:   mov    %ebp,%esp
0x411037d5 <pthread_self+37>:   pop    %ebp
0x411037d6 <pthread_self+38>:   ret

It is entirely not necessary.

> And you may not realize this, but what you propose is just another
> argument against this option.  Suddenly a DSOs marked with it interposes
> without possibility of reversal all call.  Note that this even applies

That is the whole point. Otherwise, it won't be marked with
DF_1_INTERPOSE. Are you suggesting that pthread will work if some DSO
introduces another pthread_self?

> to DSOs  which are no direct dependencies, but indirect.  This makes it
> completely invisible to the programmer.  And any late introduction of
> this flag in a DSO changes the lookup scope so dramatically that
> programs might completely fail to work.

If you are that paranoid, you can disallow it on dlopened DSOs.

> 
> LD_PRELOAD is only and exclusively a debugging or work-around tool.  It
> must not be used as a permanent solution.  The same applies to this
> flag, only it is much more severe since it affects all uses.
> 
> For me this chapter is closed: the flag has far too many problems, is
> ill-specified and generally ill-designed.

You didn't show one single problem, which doesn't exist today.

> 
> Any code which needs hacks like this is severely broken and needs to be
> redesigned.
> 

You can ignore problems, if there is any, introduced by DF_1_INTERPOSE.
Like any other features, it should be used with caution. Show me one
testcase where DF_1_INTERPOSE causes a problem. I can show you a
similar one without using DF_1_INTERPOSE.


H.J.