[RFC]: Solib search (Was: Re: Cross solib support; continued)
Daniel Jacobowitz
drow@mvista.com
Wed Nov 14 18:28:00 GMT 2001
On Tue, Nov 27, 2001 at 07:25:55PM +0100, Orjan Friberg wrote:
> Daniel Jacobowitz wrote:
> >
> > Consider if we dlopen "/lib/mmx/libc.so.6". (We never do, the dynamic
> > linker takes care of that for this particular case. But for ATLAS it's
> > another story.)
> >
> > We won't find it in solib-search-path. We won't find it if the path is
> > relative. We will only find it if we hand that entire path to openp.
> > We need to not disturb that.
>
> I'm sorry; I still fail to see your point. Let me try and break my
> thinking down, and I'd be grateful if you could point out where I'm
> wrong. To me it seems the question is whether openp should ever be fed
> an absolute path in solib_open.
>
> Using your example, if it's opened as "/lib/mmx/libc.so.6" it's an
> absolute path, so it will be handled by the following code:
Right.
> It will try and open the absolute path, prefixed by
> solib_absolute_prefix if it has been set.
Right.
> Otherwise, it will try the following:
>
> /* If not found, next search the solib_search_path (if any). */
> if (found_file < 0 && solib_search_path != NULL)
> found_file = openp (solib_search_path,
> 1, in_pathname, O_RDONLY, 0, &temp_pathname);
Also right, of course.
> If /lib/mmx/libc.so.6 was opened with a relative path, then
> solib_search_path would have to be set correctly for us to find it, no?
> What I fail to see is why we'd want openp to open an absolute path, when
> we know we want to look in solib_search_path.
We don't know that!
Suppose that I dlopen ("/lib/mmx/libc.so.6", ...). That's the case I
am describing. The only way to handle this case properly (assuming
there is also a /lib/libc.so.6) is to go through one of the absolute
path cases. There is no other option.
> > Now consider the same thing in a cross environment. This is why I very
> > strongly advocated mirroring the target filesystem. There is no other
> > way to figure out which, if any, libc.so.6 this is.
>
> I do see your point; falling back on searching on the basename only will
> certainly get me in trouble if there are several solibs with the same
> name. I also realized just now that an application's solibs won't be in
> the same directory on my host as the ones installed with the compiler,
> so I'm definitely in trouble (unless we would allow multiple solib
> search paths.) Looks like I have to take the mirrored target filesystem
> route after all. (That doesn't affect the absolute path vs openp
> question though.)
solib-search-path is colon separated; why is this a problem?
My point still holds, though.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
More information about the Gdb-patches
mailing list