Re: [Bug dynamic-link/17702] New: Support recursive dlopen.

["John D. Hendrickson" <johnandsara2 at cox dot net>]

carlos at redhat dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=17702
>
>             Bug ID: 17702
>            Summary: Support recursive dlopen.
>            Product: glibc
>            Version: 2.20
>             Status: NEW
>           Severity: normal
>           Priority: P2
>          Component: dynamic-link
>           Assignee: unassigned at sourceware dot org
>           Reporter: carlos at redhat dot com
>
> The ability to recursively call dlopen is useful for malloc implementations
> that wish to load other dynamic modules that implement reentrant/AS-safe
> functions to use in their own implementation.
>
> Given that a user malloc implementation may be called by an ongoing dlopen to
> allocate memory the user malloc implementation interrupts dlopen and if it
> calls dlopen again that's a reentrant call.
>
> At present there are two problems with this:
>
> (a) The first dlopen to return unmaps the ld.so.cache from memory resulting in
> any outer dlopens potentially referencing unmapped data (if they were in the
> middle of looking up an entry in the cache when they themselves called malloc).
>
> (b) There is code that asserts that _r_debug is RT_CONSISTENT when dlopen is
> entered. This may not be true because we may be inside another dlopen.
>
> The solution is to:
>
> (1) Change _dl_load_cache_lookup to return a copy of the mapping data, and make
> the copy using alloca/strcpy first to prevent malloc from interrupting the copy
> and potentially unmapping the cache.
>
> (2) Remove the assertion that _r_debug should be RT_CONSISTENT.
>
> (3) Work with the gdb team and write up a description of how _r_debug behaves,
> and specifically how it behaves during recursive dlopen.

dlopen should only connect to a lib, not cause any "initializations"

that's why it's called "dlopen" and not "dllrun"