This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Add RTLD_RELOAD to dlopen
- From: Florian Weimer <fweimer at redhat dot com>
- To: Samuel Thibault <samuel dot thibault at ens-lyon dot org>, libc-alpha at sourceware dot org
- Date: Thu, 3 Aug 2017 19:26:46 +0200
- Subject: Re: [PATCH] Add RTLD_RELOAD to dlopen
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=fweimer at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2B8006146B
- References: <firstname.lastname@example.org> <email@example.com>
On 08/03/2017 04:37 PM, Samuel Thibault wrote:
> So, is it OK to add this? Considering that dlmopen() brings us far from
> enough factorization for our needs, and dlopen() currently never reloads
> unless a real fat copy of the file is done (hardlinks/symlinks don't
> work, as it is based on st_ino).
I would still see a discussion of the intended symbol binding behavior.
What happens if a subsequently loaded object references a duplicated
library? Will it reference the most recent duplicate, or the original
What happens if libA depends on libB, and you need to duplicate both?
What happens with RTLD_NEXT in a duplicated object? Will it look at
earlier duplicates, too?
What happens if you reload libc.so? Your test case assumes that
reloading works for libm.so, but I think even that is a bit of a stretch.