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

["johnandsara2 at cox dot net" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17702

--- Comment #1 from 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"

-- 
You are receiving this mail because:
You are on the CC list for the bug.