This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 3/5][v3][BZ #15022] Correct global-scope dlopen issues in static executables


> > RTLD_GLOBAL isn't really meaningful here, is it?
> > The main program pseudo-object is the basis of the global scope.
> 
>  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.

>  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.)

>  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.
_dl_new_object specifically skips the logic that sets l_origin when
handling "" (the main map).  The only other place that sets l_origin
is in DL_DST_REQUIRED, which happens unless the last argument is zero.
But every caller of _dl_dst_substitute has done DL_DST_REQUIRED
beforehand, and never reaches _dl_dst_substitute when
DL_DST_REQUIRED's last argument is zero.  So now I'm convinced that
the change is indeed safe.  All that code could certainly use some
cleanup so it's less hard to follow, if someone gets inspired someday.

Go ahead and commit.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]