[lldb-dev] dlsym() and RTLD_FIRST

Tue Aug 26 16:32:24 PDT 2014

I guess the thing to do is make sure we're certain we understand the
behavior, which is perhaps best captured in a test.  (i.e. test it with the
RTLD_FIRST behavior where it does something, then verify it does something
different without the flag.  Then, once we agree it is not useful behavior
for us, look at removing it).

By valid plugin, you're referring to shared libraries, right?  (What
plugins are we referring to here, at what load point?)

On Tue, Aug 26, 2014 at 4:29 PM, Zachary Turner <zturner at google.com> wrote:

> Just as a counterpoint, unless I'm misunderstanding this code, I don't see
> it actually having a noticeable impact on stability.  The search limiting
> will only be a factor in a case where you attempt to load something that
> *isn't a valid plugin*.  It's already an error path.  In fact, this code
> worked fine before the change was made, and was only made to imitate what
> appears to have been an optimization that was Mac-specific.  The change for
> Mac doesn't seem to have been strictly necessary either, but just an
> optimization.  It's actually not an optimization for Linux, because the
> dynamic loader will still search every module on linux, it will just fail
> anyway.
>
>
> On Tue, Aug 26, 2014 at 4:21 PM, Todd Fiala <tfiala at google.com> wrote:
>
>> Probably the way I'd look at this right now is that support in Linux is a
>> bit dicey and we're doing our best to stabilize (starting with single path
>> for remote/local debugging, and making that stable and fast).  In an effort
>> to stabilize, I'd prefer to limit how much code change we do on the Linux
>> end until we have a more stable product.
>>
>> So while we could potentially take that out, I'd rather avoid making
>> changes just because it might be simpler, as it might also add yet another
>> error scenario on the Linux side.  Right now I value similarity to MacOSX
>> execution over code reduction.  Once we're a lot more stable on the Linux
>> side, I'd be much more interested in revisiting with some actual use cases
>> to see diffs in performance and scope of usage.
>>
>> Just my 2 cents...
>>
>>
>> On Tue, Aug 26, 2014 at 3:47 PM, Zachary Turner <zturner at google.com>
>> wrote:
>>
>>> The review is up on the LLVM side.  One point which was raised, and
>>> which I agree with, is that the presence of the string makes the class much
>>> heavier.  This string is only needed to mimic MacOSX's RTLD_FIRST behavior
>>> on other posix platforms.  However, going back through the history of when
>>> this was added, I never actually saw a use case from anyone saying "we
>>> *need* this on Linux".  See the full original thread at [1].  But the TL;DR
>>> is that the flag is nice to have on MacOSX, and the filename comparison was
>>> added to Linux to maintain parity.
>>>
>>> If nobody actually knows of a specific example of why this is necessary
>>> on Linux, can we just remove this behavior on Linux?  My understanding is
>>> that the only thing which will change by removing this for Linux is the
>>> following: Imagine a plugin X is loaded, and X has a library dependency on
>>> Y and Z.  X doesn't contain the plugin Initialize or Terminate symbol, but
>>> Y or Z does.  With the filename comparison code, LoadPlugin would fail, and
>>> without it, it would succeed and use the symbol found in Y or Z.  I can
>>> understand that with the comparison the algorithm is a bit better, but it
>>> seems such an extremely unusual edge case that I don't think it's a big
>>> deal to remove it from the Linux side.
>>>
>>> Thoughts?
>>>
>>> [1] -
>>> http://thread.gmane.org/gmane.comp.debugging.lldb.devel/300/focus=302
>>>
>>>
>>> On Thu, Aug 21, 2014 at 5:27 PM, Greg Clayton <gclayton at apple.com>
>>> wrote:
>>>
>>>> Sounds good to me. Hopefully if they don't want that they might accept
>>>> an extra boolean argument that can specify to only look in the current
>>>> shared library and then we can switch over to using LLVM's DynamicLibrary.
>>>>
>>>> > On Aug 21, 2014, at 4:22 PM, Zachary Turner <zturner at google.com>
>>>> wrote:
>>>> >
>>>> > This seems like the only case we ever want, so I'm going to post a
>>>> patch to LLVM's DynamicLibrary class to use RTLD_FIRST on Apple, and a
>>>> similar method of checking the module filespec on other platforms, and see
>>>> if they accept it.  If so, I will convert our Plugin code to use LLVM's
>>>> DynamicLibrary and then delete our DynamicLibrary
>>>> >
>>>> >
>>>> > On Thu, Aug 21, 2014 at 4:08 PM, Greg Clayton <gclayton at apple.com>
>>>> wrote:
>>>> >
>>>> > > On Aug 21, 2014, at 3:31 PM, Zachary Turner <zturner at google.com>
>>>> wrote:
>>>> > >
>>>> > > Can someone explain this flag to me?
>>>> >
>>>> > It says "only look in this binary, don't look in any others. We are
>>>> looking for a plug-in initialization function and we don't want to get one
>>>> back from another dylib.
>>>> >
>>>> > As Enrico said, the email from a while back details this:
>>>> >
>>>> > http://comments.gmane.org/gmane.comp.debugging.lldb.devel/305
>>>> >
>>>> > >  I've read the documentation, but it's still not clear to me.  If
>>>> you ask dlsym() to search some module X, why would it ever search modules
>>>> other than X?
>>>> >
>>>> > I don't know but it does.
>>>> >
>>>> > >
>>>> > > The reason I ask about this is that llvm support library already
>>>> has a DynamicLibrary class whose purpose almost exactly matches what we're
>>>> using the Host::DynamicLibrary related functions for.  However, it doesn't
>>>> use the RTLD_FIRST flag, and so I'm not sure what the implications are of
>>>> us using it and deleting our own DynamicLibrary code.
>>>> >
>>>> > It would be nice if we could specify this flag so we either find the
>>>> symbol from libx.dylib or we don't. We don't want to find the symbol in
>>>> liby.dylib and call it in our case.
>>>> >
>>>>
>>>>
>>>
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>
>>>
>>
>>
>> --
>>  Todd Fiala | Software Engineer |  tfiala at google.com |  650-943-3180
>>
>
>

-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140826/5ffaf6d1/attachment.html>