From: Orjan Friberg <orjan.friberg@axis.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)
Date: Tue, 27 Nov 2001 10:26:00 -0000 [thread overview]
Message-ID: <3C03DAB3.8240E639@axis.com> (raw)
Message-ID: <20011127102600.FQHVgXE-OOWwDDELxBuavwcINw8yaDk2yuMVpjFcOt0@z> (raw)
In-Reply-To: <20011127104345.A1939@nevyn.them.org>
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:
if (*p)
{
if (! IS_ABSOLUTE_PATH (in_pathname) || solib_absolute_prefix ==
NULL)
temp_pathname = in_pathname;
else
{
int prefix_len = strlen (solib_absolute_prefix);
/* Remove trailing slashes from absolute prefix. */
while (prefix_len > 0
&& IS_DIR_SEPARATOR (solib_absolute_prefix[prefix_len - 1]))
prefix_len--;
/* Cat the prefixed pathname together. */
temp_pathname = alloca (prefix_len + strlen (in_pathname) + 1);
strncpy (temp_pathname, solib_absolute_prefix, prefix_len);
temp_pathname[prefix_len] = '\0';
strcat (temp_pathname, in_pathname);
}
/* Now see if we can open it. */
found_file = open (temp_pathname, O_RDONLY, 0);
}
It will try and open the absolute path, prefixed by
solib_absolute_prefix if it has been set.
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);
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.
> 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.)
--
Orjan Friberg
Axis Communications AB
next prev parent reply other threads:[~2001-11-27 10:26 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3BEAA3A0.586B3046@axis.com>
[not found] ` <20011108110955.A12240@nevyn.them.org>
2001-11-06 10:49 ` Cross solib support; continued Orjan Friberg
2001-11-06 11:57 ` Kevin Buettner
2001-11-27 7:03 ` [RFC]: Solib search (Was: Re: Cross solib support; continued) Orjan Friberg
2001-11-14 12:49 ` Orjan Friberg
2001-11-27 7:12 ` Daniel Jacobowitz
2001-11-14 12:59 ` Daniel Jacobowitz
2001-11-14 13:21 ` Orjan Friberg
2001-11-14 13:53 ` Daniel Jacobowitz
2001-11-14 18:20 ` Orjan Friberg [this message]
2001-11-27 10:26 ` Orjan Friberg
2001-11-27 10:45 ` Daniel Jacobowitz
2001-11-14 18:28 ` Daniel Jacobowitz
2001-11-14 18:33 ` Orjan Friberg
2001-11-27 11:15 ` Orjan Friberg
2001-11-27 11:29 ` Daniel Jacobowitz
2001-11-14 18:55 ` Daniel Jacobowitz
2001-11-16 13:47 ` Orjan Friberg
2001-11-28 1:03 ` Orjan Friberg
2001-11-27 15:44 ` Kevin Buettner
2001-11-15 8:00 ` Kevin Buettner
2001-11-15 8:00 ` Daniel Jacobowitz
2001-11-15 9:16 ` Kevin Buettner
2001-11-27 16:00 ` Kevin Buettner
2001-11-27 15:47 ` Daniel Jacobowitz
2001-11-27 7:43 ` Daniel Jacobowitz
2001-11-27 7:36 ` Orjan Friberg
2001-11-27 8:00 ` Eli Zaretskii
2001-11-14 15:22 ` Eli Zaretskii
2001-11-27 10:16 ` Orjan Friberg
2001-11-14 18:14 ` Orjan Friberg
2001-11-14 20:58 ` Eli Zaretskii
2001-11-27 12:42 ` Eli Zaretskii
2001-11-28 0:55 ` Orjan Friberg
2001-11-16 13:24 ` Orjan Friberg
2001-11-28 2:00 ` Orjan Friberg
2001-11-16 14:02 ` Orjan Friberg
2001-11-17 2:18 ` Eli Zaretskii
2001-11-28 8:37 ` Eli Zaretskii
2001-11-28 9:43 ` Orjan Friberg
2001-11-17 4:03 ` Orjan Friberg
2001-11-17 12:37 ` Eli Zaretskii
2001-11-29 5:52 ` Orjan Friberg
2001-11-19 11:44 ` Orjan Friberg
2001-12-03 17:19 ` Kevin Buettner
2001-12-04 1:35 ` Orjan Friberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3C03DAB3.8240E639@axis.com \
--to=orjan.friberg@axis.com \
--cc=drow@mvista.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox