[lldb-dev] [PATCH] Host.cpp and RegisterContextLinux_x86_64.cpp fixes

[Greg Clayton]

With revision 125064 I have modified the way Host::DynamicLibaryOpen works. It now takes an abtract options that can be logical OR'ed together that allow one to specify lazy, local/global, and if Host::DynamicLibraryGetSymbol lookups should only find matches in the shared library that was opened. Systems that support RTLD_FIRST will use it, and ones that don't will do a bit of extra work to make sure this open request (find only symbols in this shared library) will be honored.

Stephen, please try it out on Linux and see if this works as you would expect.

I also switched over to either defining LLDB_CONFIG_XXX values, or not defining them to stay inline with current open source practices so we can soon use autoconf or cmake to configure LLDB.

Greg Clayton

On Feb 7, 2011, at 11:56 AM, Stephen Wilson wrote:

> Greg Clayton <gclayton at apple.com> writes:
>> So looking at our darwin man pages for dlopen, the RTLD_FIRST seems
>> like a nice flag to specify:
>> 
>> RTLD_FIRST The retuned handle is tagged so that any dlsym() calls on
>> the handle will only search the image specified, and not subsequent
>> images. If path is NULL and the option RTLD_FIRST is used, the handle
>> returned will only search the main executable.
>> 
>> We don't use NULL for the file handle for calls to dlopen, though we
>> could. Is there an equivalent option on dlsym() on linux? I don't want
>> to do code like:
> 
> No equivalent option that I know of.
> 
>> FileSpec plugin_spec ("/plugins/disassembler.dylib");
>> void *lib_handle = Host::DynamicLibraryOpen (plugin_spec, error);
>> if (lib_handle)
>> {
>>    void *init_callback = Host::DynamicLibraryGetSymbol (lib_handle, "InitPlugin", error);
>>    if (init_callback)
>>    {
>>        // Now on linux we might have a function that comes from another shared library...
>>    }
>> }
> 
> OK.  I think we should document DynamicLibaryOpen and friends so that
> the behavior is understood.  I often think of "resolving a symbol in a
> shared library" as a process which includes lookups wrt object
> dependencies since a "logical" library interface may very well be
> implemented using multiple shared objects (a c++ wrapper around a c
> library for example).
> 
>> Due to the global symbol namespace we will run into issue unless we
>> open things locally (RTLD_LOCAL), this is how unix dl calls only looks
>> into a single shared library. The main problem is the RTLD_GLOBAL is
>> sticky, so if anyone has opened a dynamic library already it will
>> already be global and it will be subject to dlsym() calls that kick up
>> any symbol in any shared library...
>> 
>> A few solutions to this is to define our own DynamicLibrary struct
>> that contains both a "void *" for the handle, and a FileSpec for the
>> path to the shared library. Then any calls to
>> Host::DynamicLibraryGetSymbol will need to verify their symbols came
>> from the shared library mentioned in the "void *".
> 
> This is exactly what we will need on linux:  DynamicLibraryGetSymbol
> will need to call dladdr(3) (glibc-specific) and compare the resolved vs
> expected library paths. 
> 
>> I will submit a patch that should fix these issues as well as add some
>> extra args to the Host::DynamicLibraryOpen and
>> Host::DynamicLibraryGetSymbol calls that will allow for more control
>> over this process.
> 
> Great.  I'll watch for the commits and implement/test anything that is
> needed on the linux side.
> 
>> 
>> Greg Clayton
>> 
> 
> --
> steve