This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Should glibc be fully reentrant? What do we allow interposed symbols to do?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 22 Oct 2014 22:29:20 -0400
- Subject: Should glibc be fully reentrant? What do we allow interposed symbols to do?
- Authentication-results: sourceware.org; auth=none
- References: <54456FA1 dot 9070804 at redhat dot com> <20141020204153 dot 83C542C3B0D at topped-with-meat dot com> <54457C4C dot 4080307 at redhat dot com> <20141021224739 dot 080382C3AB2 at topped-with-meat dot com>
On 10/21/2014 06:47 PM, Roland McGrath wrote:
> But the slippery slope concerns me most of all.
Any function the user interposes acts as a synchronous interrupt on the
runtime.
It is my opinion that users expect to be able to call any routine in the
runtime without caution unless we tell them otherwise.
Given that dlopen locks are recursive, as are stdio locks, I propose we
fully support this notion that users already believe exists.
The alternative is that we don't support it and treat interposed functions
as if they were in a signal handler context, only being allowed to call
async-signal-safe functions, and we might as well remove the recursive
support from the locks such that users get useful backtraces from deadlocks.
It is my opinion that such a direction would not help our users and would
not help the project.
The similar situations we need to clarify are LD_AUDIT modules, and
IFUNC resolvers, but let us proceed orderly one topic at a time.
In summary
==========
Allow interposed functions to call back into the runtime, and fix any
places where this breaks.
Cheers,
Carlos.