This is the mail archive of the
mailing list for the binutils project.
Re: Recursive function calls vs. ELF shared libraries
- From: Nico Williams <nico at cryptonector dot com>
- To: binutils at sourceware dot org
- Date: Mon, 6 May 2013 15:53:07 -0500
- Subject: Re: Recursive function calls vs. ELF shared libraries
- References: <20130506040124 dot GB5221 at bubble dot grove dot modra dot org>
On Sun, May 5, 2013 at 11:01 PM, Alan Modra <firstname.lastname@example.org> wrote:
> So we have a self-call using a global symbol that g++ treats as a
> local call. This was ((GCC) 4.7.2 20120921 (Red Hat 4.7.2-2)). I
> reckon g++ is incorrect.
> We know that ELF shared library symbol resolution rules say that any
> global default visibility symbol can be overridden by a definition in
> the executable or another shared library earlier in search order, so
> generally you can't assume a call like this is local when compiling
> with -fPIC. Indeed, g++ doesn't do so for other symbols, just the
Well, there's also versioned symbols, which can be used to simulate
Solaris-style direct binding. If this is used then the only way to
interpose on a self-call would have to be to mark a symbol earlier in
the global link map as INTERPOSE (Solaris), or place an
equally-versioned symbol earlier in the global link map.
Is it useful to intercept self-calls? I can't think of a case where
I've wanted to, but I have definitely used explicit interposition
(LD_PRELOAD) on intra-shared object calls (e.g., from a function in
libc to a function in libc). This is incredibly useful and should not
What is NOT useful is accidental interposition.
> You might think that if execution arrived at this function, then
> another call via the same symbol ought to get there too, but I can
> imagine a situation where this isn't so. For example, the main
> executable might override this function, perhaps for as innocuous a
> reason as counting the number of calls, then call the library
> function via a pointer. If we go direct then some calls are missed by
> the executable interceptor. Another type of interception might effect
> a "patch" of the library function for some parameter values.
> Or am I off in the weeds here?
You're not. The ability to interpose purposefully, even on self-calls
by exported/global (but not protected) functions.