This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 3/5][v3][BZ #15022] Correct global-scope dlopen issues in static executables
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Fri, 28 Jun 2013 16:36:23 +0100
- Subject: Re: [PATCH 3/5][v3][BZ #15022] Correct global-scope dlopen issues in static executables
- References: <alpine dot DEB dot 1 dot 10 dot 1301152056590 dot 4834 at tp dot orcam dot me dot uk> <20130116215545 dot 7A37A2C0B0 at topped-with-meat dot com> <alpine dot DEB dot 1 dot 10 dot 1301240655220 dot 4834 at tp dot orcam dot me dot uk> <20130531200059 dot C94C02C077 at topped-with-meat dot com> <alpine dot DEB dot 1 dot 10 dot 1306140202520 dot 16287 at tp dot orcam dot me dot uk> <20130621223729 dot 489852C14C at topped-with-meat dot com> <alpine dot DEB dot 1 dot 10 dot 1306271643210 dot 16287 at tp dot orcam dot me dot uk> <20130627220905 dot 778E12C091 at topped-with-meat dot com>
On Thu, 27 Jun 2013, Roland McGrath wrote:
> > Well, either of RTLD_GLOBAL or RTLD_LOCAL should work here and one has to
> > be specified. I use RTLD_LOCAL later on, so I think RTLD_GLOBAL makes
> > sense here for diversity.
>
> RTLD_GLOBAL is a strange feature that should rarely be used. So if
> you are using it at all, it should be clear why. "Diversity" as a
> rationale makes sense only if you are doing an exhaustive test of the
> permutations. IMHO what makes sense is to have tests that verify the
> functionality and don't randomly use things whose behavior they are
> not testing in detail.
Exhaustive testing would be ideal, but is not always possible or feasible
with the resources available. Given a black box (here the library) we
want to verify that operates according to spec, I think it makes sense to
try various kinds of inputs that are supposed not to influence output to
make sure that they indeed do not.
> > While looking into it I've noticed we don't actually have any RTLD_GLOBAL
> > vs RTLD_LOCAL semantics tests. I think with little tweaking tststatic4
> > can be adjusted to serve as such a test, for regular dynamic access (i.e.
> > from a dynamic executable). I'll try to cook up something based on that,
> > sometime (unless you or someone else beats me to it, that is).
>
> Please do. tststatic4 looks like it does some amount of that. But a
> dynamically-linked case doing that stuff is certainly warranted too.
> (Most or all of the dlfcn tests really ought to be built in both
> dynamic and static variants to verify that everything works both
> ways.)
OK, I'll see what I can do.
> > Thanks. I've decided to post the new version after all as I found
> > another place, in dl-load.c, where I think a piece of !SHARED code can be
> > removed. With the addition of .l_origin initialisation to
> > _dl_non_dynamic_init I believe there is not going to be a case where this
> > member is null at the time _dl_dst_substitute is called. Please confirm
> > my understanding. I saw no regressions in MIPS testing with this update.
>
> I don't really doubt that you're right. But off hand it's not clear
> to me where the main map's l_origin gets set in the dynamic case.
Given the !SHARED wrapping around the piece removed only static execution
paths need be checked. Of course that does not mean the shared ones are
good, but that does not matter for the change I proposed. Thanks however
for taking the opportunity to check them too.
> Go ahead and commit.
Applied now, thanks for your review.
Maciej