Recursive function calls vs. ELF shared libraries

John Reiser jreiser@bitwagon.com
Mon May 6 18:47:00 GMT 2013


On 05/05/2013 09:01 PM, Alan Modra 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.

If this were C, then definitely it would be a compiler bug.

Could this be an application of C++ "one definition rule"?
I'd call it a perversion of the rule, because I believe that _every_
lexical reference to a global symbol should be eligible for overriding
by the ELF shared library symbol resolution rules.
I use the rules for the purpose of profiling, or for
specialization depending on values of actual arguments,
or for tracking very specific bugs, etc.
These are the cases you imagine in your next two paragraphs:

> 
> 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
> self-calls.
> 
> 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?

No, I consider that you are correct.

-- 



More information about the Binutils mailing list