Re: Recursive function calls vs. ELF shared libraries

[Cary Coutant <ccoutant at google dot com>]

> 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?

Not sure you're off in the weeds, but I'd be deeply suspicious of any
program that tried to take advantage of what you're describing.

In the HP-UX runtime, we established a policy that any global symbol
defined in the same compilation unit could be treated as a protected
symbol for the purposes of binding -- i.e., the compiler could treat
calls to a function in the same CU as a local call. I called this
"archive-equivalence", justifying this behavior on the grounds that
any program that actually did override a symbol in this situation, if
linked statically, would get a duplicate symbol error unless the CU
with the intercepted call was not referenced (in which case the
failure to override is irrelevant). This policy helped improve
performance of the generated PIC code fairly substantially, and I'm
not aware of any problems where a customer expected a symbol to be
intercepted.

So I think the idea that you can treat the recursive call as a local
call is fine.

-cary