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

[Stephen Wilson]

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