I actually already got the patch put together. I posted in another thread. I don't know how to test plugin code, so if you or someone else there is willing to help out and check that it works as expected, I would appreciate it.
On Thu, Aug 21, 2014 at 5:27 PM, Greg Clayton <gclay...@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 <ztur...@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 <gclay...@apple.com> > wrote: > > > > > On Aug 21, 2014, at 3:31 PM, Zachary Turner <ztur...@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@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
