Re: Cross solib support; continued

Re: Cross solib support; continued

[Orjan Friberg]

Daniel Jacobowitz wrote:
> 
> On Thu, Nov 08, 2001 at 04:24:16PM +0100, Orjan Friberg wrote:
> > A couple of more questions regarding support for cross solibs:
> >
> > That is, I would like a solib that is now searched for in
> > solib-absolute-prefix to be searched for in solib-search-path instead.
> > Would it make sense to add such a command, like solib-ignore-path?  (I'd
> > be happy to make it happen.)  In effect, it would make all solibs to be
> > searched for in solib-search-path by file name only, and
> > solib-absolute-path would have no effect.
> 
> Is this really necessary?  I just put unstripped libraries in a
> directory named lib and set the absolute prefix appropriately.
> 
> Other than that, we should fall back to solib-search-path and the
> basename if solib-absolute-path fails for us, IMO.  Would that work for
> you?  Set the absolute-path to /dev/null or so and then add the
> fallback code.

FYI: I'm not twiddling my thumbs waiting for you or anybody else to
implement this for me.  I'm willing to dig in and do it, but I'm
currently swamped in other things, and will probably be so for a few
more days.  As they say, "It's on my TODO list."

-- 
Orjan Friberg
Axis Communications AB

Re: Cross solib support; continued

[Kevin Buettner]

On Nov 15,  7:23pm, Orjan Friberg wrote:

> > > That is, I would like a solib that is now searched for in
> > > solib-absolute-prefix to be searched for in solib-search-path instead.
> > > Would it make sense to add such a command, like solib-ignore-path?  (I'd
> > > be happy to make it happen.)  In effect, it would make all solibs to be
> > > searched for in solib-search-path by file name only, and
> > > solib-absolute-path would have no effect.
> > 
> > Is this really necessary?  I just put unstripped libraries in a
> > directory named lib and set the absolute prefix appropriately.
> > 
> > Other than that, we should fall back to solib-search-path and the
> > basename if solib-absolute-path fails for us, IMO.  Would that work for
> > you?  Set the absolute-path to /dev/null or so and then add the
> > fallback code.
> 
> FYI: I'm not twiddling my thumbs waiting for you or anybody else to
> implement this for me.  I'm willing to dig in and do it, but I'm
> currently swamped in other things, and will probably be so for a few
> more days.  As they say, "It's on my TODO list."

Good.  Daniel's suggested approach to solving your problem sounds okay
to me so a patch based on his suggestion should be okay too.

Thanks,

Kevin

[RFC]: Solib search (Was: Re: Cross solib support; continued)

[Orjan Friberg]

Daniel Jacobowitz wrote:
> 
> Other than that, we should fall back to solib-search-path and the
> basename if solib-absolute-path fails for us, IMO.  Would that work for
> you?  Set the absolute-path to /dev/null or so and then add the
> fallback code.

A quick recap: I'm doing solib debugging in a cross-environment, but the path to the
target's solibs on my host doesn't correspond to the path on the target.  More
specifically, the path where I want to get the solibs from on my host doesn't end in
/lib.

This is a first shot at it.  The latter part of the patch implements what Daniel
suggested, but the first part is more controversial.  The problem is when in_pathname
contains an absolute path (say /lib/libc.so.6), but it's not found in the path
specified by solib_absolute_prefix.  When we try and search for the solib in
solib_search_path, openp will find that the file name is an absolute path and open it
(ignoring the supplied solib_search_path).  As a result, it will pick up
/lib/libc.so.6 on my host.

My thought was to make the path relative if the search for the absolute path failed,
by simply getting rid of the leading '/'.  (It won't work with DOS based file
systems, as the dir separator could be '\\', but that would be easy to add.) 
Needless to say, this works for me, but I'm not sure it's The Right Thing to do. 
(Another approach would be to change openp, but I'm sure there's a good reason for
its current behaviour.)


2001-11-27  Orjan Friberg  <orjanf@axis.com>

	* solib.c (solib_open): Make path relative if search for absolute path
	failed.  If search for relative path in solib_search_path failed, fall
	back to search for basename only.


Index: solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.45
diff -u -r1.45 solib.c
--- solib.c     2001/11/01 16:17:08     1.45
+++ solib.c     2001/11/27 14:31:15
@@ -131,10 +131,25 @@
       found_file = open (temp_pathname, O_RDONLY, 0);
     }
 
+  /* If the search in solib_absolute_prefix failed, and the path name is
+     absolute at this point, make it relative.  (openp will try and open the
+     file according to its absolute path otherwise, which is not what we want.)
+     Affects all subsequent searches for this solib.  */
+  if (found_file < 0 && IS_DIR_SEPARATOR (in_pathname[0]))
+    in_pathname++;
+
   /* 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 not found, next search the solib_search_path (if any) for the
+     basename only (ignoring the path).  This is to allow reading solibs
+     from a path that doesn't end in, say, /lib.  */
+  if (found_file < 0 && solib_search_path != NULL)
+    found_file = openp (solib_search_path, 
+                        1, lbasename (in_pathname), O_RDONLY, 0,
+                        &temp_pathname);
 
   /* If not found, next search the inferior's $PATH environment variable. */
   if (found_file < 0 && solib_search_path != NULL)

-- 
Orjan Friberg
Axis Communications AB

[RFC]: Solib search (Was: Re: Cross solib support; continued)

[Orjan Friberg]

Daniel Jacobowitz wrote:
> 
> Other than that, we should fall back to solib-search-path and the
> basename if solib-absolute-path fails for us, IMO.  Would that work for
> you?  Set the absolute-path to /dev/null or so and then add the
> fallback code.

A quick recap: I'm doing solib debugging in a cross-environment, but the path to the
target's solibs on my host doesn't correspond to the path on the target.  More
specifically, the path where I want to get the solibs from on my host doesn't end in
/lib.

This is a first shot at it.  The latter part of the patch implements what Daniel
suggested, but the first part is more controversial.  The problem is when in_pathname
contains an absolute path (say /lib/libc.so.6), but it's not found in the path
specified by solib_absolute_prefix.  When we try and search for the solib in
solib_search_path, openp will find that the file name is an absolute path and open it
(ignoring the supplied solib_search_path).  As a result, it will pick up
/lib/libc.so.6 on my host.

My thought was to make the path relative if the search for the absolute path failed,
by simply getting rid of the leading '/'.  (It won't work with DOS based file
systems, as the dir separator could be '\\', but that would be easy to add.) 
Needless to say, this works for me, but I'm not sure it's The Right Thing to do. 
(Another approach would be to change openp, but I'm sure there's a good reason for
its current behaviour.)


2001-11-27  Orjan Friberg  <orjanf@axis.com>

	* solib.c (solib_open): Make path relative if search for absolute path
	failed.  If search for relative path in solib_search_path failed, fall
	back to search for basename only.


Index: solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.45
diff -u -r1.45 solib.c
--- solib.c     2001/11/01 16:17:08     1.45
+++ solib.c     2001/11/27 14:31:15
@@ -131,10 +131,25 @@
       found_file = open (temp_pathname, O_RDONLY, 0);
     }
 
+  /* If the search in solib_absolute_prefix failed, and the path name is
+     absolute at this point, make it relative.  (openp will try and open the
+     file according to its absolute path otherwise, which is not what we want.)
+     Affects all subsequent searches for this solib.  */
+  if (found_file < 0 && IS_DIR_SEPARATOR (in_pathname[0]))
+    in_pathname++;
+
   /* 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 not found, next search the solib_search_path (if any) for the
+     basename only (ignoring the path).  This is to allow reading solibs
+     from a path that doesn't end in, say, /lib.  */
+  if (found_file < 0 && solib_search_path != NULL)
+    found_file = openp (solib_search_path, 
+                        1, lbasename (in_pathname), O_RDONLY, 0,
+                        &temp_pathname);
 
   /* If not found, next search the inferior's $PATH environment variable. */
   if (found_file < 0 && solib_search_path != NULL)

-- 
Orjan Friberg
Axis Communications AB

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Daniel Jacobowitz]

On Tue, Nov 27, 2001 at 04:03:45PM +0100, Orjan Friberg wrote:
> Daniel Jacobowitz wrote:
> > 
> > Other than that, we should fall back to solib-search-path and the
> > basename if solib-absolute-path fails for us, IMO.  Would that work for
> > you?  Set the absolute-path to /dev/null or so and then add the
> > fallback code.
> 
> A quick recap: I'm doing solib debugging in a cross-environment, but the path to the
> target's solibs on my host doesn't correspond to the path on the target.  More
> specifically, the path where I want to get the solibs from on my host doesn't end in
> /lib.
> 
> This is a first shot at it.  The latter part of the patch implements what Daniel
> suggested, but the first part is more controversial.  The problem is when in_pathname
> contains an absolute path (say /lib/libc.so.6), but it's not found in the path
> specified by solib_absolute_prefix.  When we try and search for the solib in
> solib_search_path, openp will find that the file name is an absolute path and open it
> (ignoring the supplied solib_search_path).  As a result, it will pick up
> /lib/libc.so.6 on my host.
> 
> My thought was to make the path relative if the search for the absolute path failed,
> by simply getting rid of the leading '/'.  (It won't work with DOS based file
> systems, as the dir separator could be '\\', but that would be easy to add.) 
> Needless to say, this works for me, but I'm not sure it's The Right Thing to do. 
> (Another approach would be to change openp, but I'm sure there's a good reason for
> its current behaviour.)

I've got one concern with this.  In native debugging, we want to open
the absolute path BEFORE searching solib-search-path - you might have
dlopened() a specific optimized version of a library whose base exists
in /usr/lib, for instance.

Perhaps you need to propogate knowledge of whether we are debugging
natively down to this point?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Daniel Jacobowitz]

On Tue, Nov 27, 2001 at 04:03:45PM +0100, Orjan Friberg wrote:
> Daniel Jacobowitz wrote:
> > 
> > Other than that, we should fall back to solib-search-path and the
> > basename if solib-absolute-path fails for us, IMO.  Would that work for
> > you?  Set the absolute-path to /dev/null or so and then add the
> > fallback code.
> 
> A quick recap: I'm doing solib debugging in a cross-environment, but the path to the
> target's solibs on my host doesn't correspond to the path on the target.  More
> specifically, the path where I want to get the solibs from on my host doesn't end in
> /lib.
> 
> This is a first shot at it.  The latter part of the patch implements what Daniel
> suggested, but the first part is more controversial.  The problem is when in_pathname
> contains an absolute path (say /lib/libc.so.6), but it's not found in the path
> specified by solib_absolute_prefix.  When we try and search for the solib in
> solib_search_path, openp will find that the file name is an absolute path and open it
> (ignoring the supplied solib_search_path).  As a result, it will pick up
> /lib/libc.so.6 on my host.
> 
> My thought was to make the path relative if the search for the absolute path failed,
> by simply getting rid of the leading '/'.  (It won't work with DOS based file
> systems, as the dir separator could be '\\', but that would be easy to add.) 
> Needless to say, this works for me, but I'm not sure it's The Right Thing to do. 
> (Another approach would be to change openp, but I'm sure there's a good reason for
> its current behaviour.)

I've got one concern with this.  In native debugging, we want to open
the absolute path BEFORE searching solib-search-path - you might have
dlopened() a specific optimized version of a library whose base exists
in /usr/lib, for instance.

Perhaps you need to propogate knowledge of whether we are debugging
natively down to this point?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Orjan Friberg]

Daniel Jacobowitz wrote:
> 
> On Tue, Nov 27, 2001 at 04:03:45PM +0100, Orjan Friberg wrote:
> >
> > My thought was to make the path relative if the search for the absolute path failed,
> > by simply getting rid of the leading '/'.  (It won't work with DOS based file
> > systems, as the dir separator could be '\\', but that would be easy to add.)
> > Needless to say, this works for me, but I'm not sure it's The Right Thing to do.
> > (Another approach would be to change openp, but I'm sure there's a good reason for
> > its current behaviour.)
> 
> I've got one concern with this.  In native debugging, we want to open
> the absolute path BEFORE searching solib-search-path - you might have
> dlopened() a specific optimized version of a library whose base exists
> in /usr/lib, for instance.

I'm not sure I follow: wouldn't that be covered by solib_absolute_prefix being set to
/usr/lib?  I mean, I haven't changed the order between searching in
solib_absolute_prefix and solib_search_path.  Or do you mean the case where
solib_absolute_prefix isn't set, and we end up searching for it using
LD_LIBRARY_PATH?  Hm, maybe we should only make the path relative if we are about to
search for the solib in solib_search_path, leaving the other cases unaffected.

-- 
Orjan Friberg
Axis Communications AB

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Daniel Jacobowitz]

On Tue, Nov 27, 2001 at 04:36:08PM +0100, Orjan Friberg wrote:
> Daniel Jacobowitz wrote:
> > 
> > On Tue, Nov 27, 2001 at 04:03:45PM +0100, Orjan Friberg wrote:
> > >
> > > My thought was to make the path relative if the search for the absolute path failed,
> > > by simply getting rid of the leading '/'.  (It won't work with DOS based file
> > > systems, as the dir separator could be '\\', but that would be easy to add.)
> > > Needless to say, this works for me, but I'm not sure it's The Right Thing to do.
> > > (Another approach would be to change openp, but I'm sure there's a good reason for
> > > its current behaviour.)
> > 
> > I've got one concern with this.  In native debugging, we want to open
> > the absolute path BEFORE searching solib-search-path - you might have
> > dlopened() a specific optimized version of a library whose base exists
> > in /usr/lib, for instance.
> 
> I'm not sure I follow: wouldn't that be covered by solib_absolute_prefix being set to
> /usr/lib?  I mean, I haven't changed the order between searching in
> solib_absolute_prefix and solib_search_path.  Or do you mean the case where
> solib_absolute_prefix isn't set, and we end up searching for it using
> LD_LIBRARY_PATH?  Hm, maybe we should only make the path relative if we are about to
> search for the solib in solib_search_path, leaving the other cases unaffected.

That sounds a little better.  If there's a /lib/lib or a
/usr/lib/usr/lib it's their own fault.  I'm still not convinced,
though.

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.

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.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Orjan Friberg]

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

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Orjan Friberg]

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

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Daniel Jacobowitz]

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

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Daniel Jacobowitz]

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

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Orjan Friberg]

Daniel Jacobowitz wrote:
> 
> 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.

But won't dlopen ("/lib/mmx/libc.so.6", ...) be handled by:

  if (! IS_ABSOLUTE_PATH (in_pathname) || solib_absolute_prefix == NULL)
    temp_pathname = in_pathname;
  else
    {
      [Catting of prefix and pathname]
    }

  /* Now see if we can open it.  */
  found_file = open (temp_pathname, O_RDONLY, 0);

That counts as an absolute path case, right?

I can't see why we'd rely on the first openp to handle dlopen ("/lib/mmx/libc.so.6",
...) since it's an absolute path and should be handled by the code above.  That's why
I suggest we know we should look in solib_search_path (and thus should get rid of the
leading '/' which makes it an absolute path).

> solib-search-path is colon separated; why is this a problem?

No problem; my bad.  I didn't know solib-search-path could be colon separated, though
I see that now in openp.

-- 
Orjan Friberg
Axis Communications AB

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Orjan Friberg]

Daniel Jacobowitz wrote:
> 
> 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.

But won't dlopen ("/lib/mmx/libc.so.6", ...) be handled by:

  if (! IS_ABSOLUTE_PATH (in_pathname) || solib_absolute_prefix == NULL)
    temp_pathname = in_pathname;
  else
    {
      [Catting of prefix and pathname]
    }

  /* Now see if we can open it.  */
  found_file = open (temp_pathname, O_RDONLY, 0);

That counts as an absolute path case, right?

I can't see why we'd rely on the first openp to handle dlopen ("/lib/mmx/libc.so.6",
...) since it's an absolute path and should be handled by the code above.  That's why
I suggest we know we should look in solib_search_path (and thus should get rid of the
leading '/' which makes it an absolute path).

> solib-search-path is colon separated; why is this a problem?

No problem; my bad.  I didn't know solib-search-path could be colon separated, though
I see that now in openp.

-- 
Orjan Friberg
Axis Communications AB

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Daniel Jacobowitz]

On Tue, Nov 27, 2001 at 08:15:44PM +0100, Orjan Friberg wrote:
> Daniel Jacobowitz wrote:
> > 
> > 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.
> 
> But won't dlopen ("/lib/mmx/libc.so.6", ...) be handled by:
> 
>   if (! IS_ABSOLUTE_PATH (in_pathname) || solib_absolute_prefix == NULL)
>     temp_pathname = in_pathname;
>   else
>     {
>       [Catting of prefix and pathname]
>     }
> 
>   /* Now see if we can open it.  */
>   found_file = open (temp_pathname, O_RDONLY, 0);
> 
> That counts as an absolute path case, right?
> 
> I can't see why we'd rely on the first openp to handle dlopen ("/lib/mmx/libc.so.6",
> ...) since it's an absolute path and should be handled by the code above.  That's why
> I suggest we know we should look in solib_search_path (and thus should get rid of the
> leading '/' which makes it an absolute path).

Oh!  I was confused; sorry.

I think your patch is OK.  If we fail to find it in the absolute path,
search for its "absolute" (without leading directory separator[s])
path in each directory in the solib-search-path.  Then try searching
for its basename as a last resort.  Right?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Daniel Jacobowitz]

On Tue, Nov 27, 2001 at 08:15:44PM +0100, Orjan Friberg wrote:
> Daniel Jacobowitz wrote:
> > 
> > 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.
> 
> But won't dlopen ("/lib/mmx/libc.so.6", ...) be handled by:
> 
>   if (! IS_ABSOLUTE_PATH (in_pathname) || solib_absolute_prefix == NULL)
>     temp_pathname = in_pathname;
>   else
>     {
>       [Catting of prefix and pathname]
>     }
> 
>   /* Now see if we can open it.  */
>   found_file = open (temp_pathname, O_RDONLY, 0);
> 
> That counts as an absolute path case, right?
> 
> I can't see why we'd rely on the first openp to handle dlopen ("/lib/mmx/libc.so.6",
> ...) since it's an absolute path and should be handled by the code above.  That's why
> I suggest we know we should look in solib_search_path (and thus should get rid of the
> leading '/' which makes it an absolute path).

Oh!  I was confused; sorry.

I think your patch is OK.  If we fail to find it in the absolute path,
search for its "absolute" (without leading directory separator[s])
path in each directory in the solib-search-path.  Then try searching
for its basename as a last resort.  Right?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Orjan Friberg]

Daniel Jacobowitz wrote:
> 
> On Tue, Nov 27, 2001 at 08:15:44PM +0100, Orjan Friberg wrote:
> > Daniel Jacobowitz wrote:
> > >
> > > 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.
> >
> > But won't dlopen ("/lib/mmx/libc.so.6", ...) be handled by:
> >
> >   if (! IS_ABSOLUTE_PATH (in_pathname) || solib_absolute_prefix == NULL)
> >     temp_pathname = in_pathname;
> >   else
> >     {
> >       [Catting of prefix and pathname]
> >     }
> >
> >   /* Now see if we can open it.  */
> >   found_file = open (temp_pathname, O_RDONLY, 0);
> >
> > That counts as an absolute path case, right?
> >
> > I can't see why we'd rely on the first openp to handle dlopen ("/lib/mmx/libc.so.6",
> > ...) since it's an absolute path and should be handled by the code above.  That's why
> > I suggest we know we should look in solib_search_path (and thus should get rid of the
> > leading '/' which makes it an absolute path).
> 
> Oh!  I was confused; sorry.

No problem; thanks for taking the time to review my patch.

> I think your patch is OK.  If we fail to find it in the absolute path,
> search for its "absolute" (without leading directory separator[s])
> path in each directory in the solib-search-path.  Then try searching
> for its basename as a last resort.  Right?

Right.  (And if basename search fails, we search $PATH and $LD_LIBRARY_PATH like
before.)  I will post an updated patch shortly.

-- 
Orjan Friberg
Axis Communications AB

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Orjan Friberg]

Daniel Jacobowitz wrote:
> 
> On Tue, Nov 27, 2001 at 08:15:44PM +0100, Orjan Friberg wrote:
> > Daniel Jacobowitz wrote:
> > >
> > > 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.
> >
> > But won't dlopen ("/lib/mmx/libc.so.6", ...) be handled by:
> >
> >   if (! IS_ABSOLUTE_PATH (in_pathname) || solib_absolute_prefix == NULL)
> >     temp_pathname = in_pathname;
> >   else
> >     {
> >       [Catting of prefix and pathname]
> >     }
> >
> >   /* Now see if we can open it.  */
> >   found_file = open (temp_pathname, O_RDONLY, 0);
> >
> > That counts as an absolute path case, right?
> >
> > I can't see why we'd rely on the first openp to handle dlopen ("/lib/mmx/libc.so.6",
> > ...) since it's an absolute path and should be handled by the code above.  That's why
> > I suggest we know we should look in solib_search_path (and thus should get rid of the
> > leading '/' which makes it an absolute path).
> 
> Oh!  I was confused; sorry.

No problem; thanks for taking the time to review my patch.

> I think your patch is OK.  If we fail to find it in the absolute path,
> search for its "absolute" (without leading directory separator[s])
> path in each directory in the solib-search-path.  Then try searching
> for its basename as a last resort.  Right?

Right.  (And if basename search fails, we search $PATH and $LD_LIBRARY_PATH like
before.)  I will post an updated patch shortly.

-- 
Orjan Friberg
Axis Communications AB

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Kevin Buettner]

On Nov 27,  2:29pm, Daniel Jacobowitz wrote:

> I think your patch is OK.  If we fail to find it in the absolute path,
> search for its "absolute" (without leading directory separator[s])
> path in each directory in the solib-search-path.  Then try searching
> for its basename as a last resort.  Right?

I don't like it.  In particular, the part I don't like is:

+  /* If the search in solib_absolute_prefix failed, and the path name is
+     absolute at this point, make it relative.  (openp will try and open the
+     file according to its absolute path otherwise, which is not what we want.)
+     Affects all subsequent searches for this solib.  */
+  if (found_file < 0 && IS_DIR_SEPARATOR (in_pathname[0]))
+    in_pathname++;
+

I do understand Orjan's reasons for doing this, but it seems rather
fragile to me.  I think that we'd be better off doing one of the
following:

    1) Change openp()'s behavior so that it (optionally) doesn't
       attempt to open a file (which has an absolute path).  I.e,
       force it to only consider the paths that we pass it.

    2) Explicitly prepend solib_absolute_prefix to the path in question
       and pass that to openp().  Or, perhaps openp() doesn't even need
       to be called.  Perhaps we can do the job with open().

Of these two, I like the second better.

Kevin

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Daniel Jacobowitz]

On Tue, Nov 27, 2001 at 04:44:28PM -0700, Kevin Buettner wrote:
> On Nov 27,  2:29pm, Daniel Jacobowitz wrote:
> 
> > I think your patch is OK.  If we fail to find it in the absolute path,
> > search for its "absolute" (without leading directory separator[s])
> > path in each directory in the solib-search-path.  Then try searching
> > for its basename as a last resort.  Right?
> 
> I don't like it.  In particular, the part I don't like is:
> 
> +  /* If the search in solib_absolute_prefix failed, and the path name is
> +     absolute at this point, make it relative.  (openp will try and open the
> +     file according to its absolute path otherwise, which is not what we want.)
> +     Affects all subsequent searches for this solib.  */
> +  if (found_file < 0 && IS_DIR_SEPARATOR (in_pathname[0]))
> +    in_pathname++;
> +
> 
> I do understand Orjan's reasons for doing this, but it seems rather
> fragile to me.  I think that we'd be better off doing one of the
> following:
> 
>     1) Change openp()'s behavior so that it (optionally) doesn't
>        attempt to open a file (which has an absolute path).  I.e,
>        force it to only consider the paths that we pass it.
> 
>     2) Explicitly prepend solib_absolute_prefix to the path in question
>        and pass that to openp().  Or, perhaps openp() doesn't even need
>        to be called.  Perhaps we can do the job with open().

If I understand correctly, that's not what he was trying to accomplish. 
He was trying to have openp() search for the "absolute" path after each
member of solib-search-path.  Am I wrong?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Kevin Buettner]

On Nov 27,  6:48pm, Daniel Jacobowitz wrote:

> On Tue, Nov 27, 2001 at 04:44:28PM -0700, Kevin Buettner wrote:
> > On Nov 27,  2:29pm, Daniel Jacobowitz wrote:
> > 
> > > I think your patch is OK.  If we fail to find it in the absolute path,
> > > search for its "absolute" (without leading directory separator[s])
> > > path in each directory in the solib-search-path.  Then try searching
> > > for its basename as a last resort.  Right?
> > 
> > I don't like it.  In particular, the part I don't like is:
> > 
> > +  /* If the search in solib_absolute_prefix failed, and the path name is
> > +     absolute at this point, make it relative.  (openp will try and open the
> > +     file according to its absolute path otherwise, which is not what we want.)
> > +     Affects all subsequent searches for this solib.  */
> > +  if (found_file < 0 && IS_DIR_SEPARATOR (in_pathname[0]))
> > +    in_pathname++;
> > +
> > 
> > I do understand Orjan's reasons for doing this, but it seems rather
> > fragile to me.  I think that we'd be better off doing one of the
> > following:
> > 
> >     1) Change openp()'s behavior so that it (optionally) doesn't
> >        attempt to open a file (which has an absolute path).  I.e,
> >        force it to only consider the paths that we pass it.
> > 
> >     2) Explicitly prepend solib_absolute_prefix to the path in question
> >        and pass that to openp().  Or, perhaps openp() doesn't even need
> >        to be called.  Perhaps we can do the job with open().
> 
> If I understand correctly, that's not what he was trying to accomplish. 
> He was trying to have openp() search for the "absolute" path after each
> member of solib-search-path.  Am I wrong?

You're right.  (I misread part of the patch.)

I just looked at the patch again.  Now that I look at it some more, I
think it's okay so long as Eli's concerns are addressed.

Kevin

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Kevin Buettner]

On Nov 27,  6:48pm, Daniel Jacobowitz wrote:

> On Tue, Nov 27, 2001 at 04:44:28PM -0700, Kevin Buettner wrote:
> > On Nov 27,  2:29pm, Daniel Jacobowitz wrote:
> > 
> > > I think your patch is OK.  If we fail to find it in the absolute path,
> > > search for its "absolute" (without leading directory separator[s])
> > > path in each directory in the solib-search-path.  Then try searching
> > > for its basename as a last resort.  Right?
> > 
> > I don't like it.  In particular, the part I don't like is:
> > 
> > +  /* If the search in solib_absolute_prefix failed, and the path name is
> > +     absolute at this point, make it relative.  (openp will try and open the
> > +     file according to its absolute path otherwise, which is not what we want.)
> > +     Affects all subsequent searches for this solib.  */
> > +  if (found_file < 0 && IS_DIR_SEPARATOR (in_pathname[0]))
> > +    in_pathname++;
> > +
> > 
> > I do understand Orjan's reasons for doing this, but it seems rather
> > fragile to me.  I think that we'd be better off doing one of the
> > following:
> > 
> >     1) Change openp()'s behavior so that it (optionally) doesn't
> >        attempt to open a file (which has an absolute path).  I.e,
> >        force it to only consider the paths that we pass it.
> > 
> >     2) Explicitly prepend solib_absolute_prefix to the path in question
> >        and pass that to openp().  Or, perhaps openp() doesn't even need
> >        to be called.  Perhaps we can do the job with open().
> 
> If I understand correctly, that's not what he was trying to accomplish. 
> He was trying to have openp() search for the "absolute" path after each
> member of solib-search-path.  Am I wrong?

You're right.  (I misread part of the patch.)

I just looked at the patch again.  Now that I look at it some more, I
think it's okay so long as Eli's concerns are addressed.

Kevin

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Daniel Jacobowitz]

On Tue, Nov 27, 2001 at 04:44:28PM -0700, Kevin Buettner wrote:
> On Nov 27,  2:29pm, Daniel Jacobowitz wrote:
> 
> > I think your patch is OK.  If we fail to find it in the absolute path,
> > search for its "absolute" (without leading directory separator[s])
> > path in each directory in the solib-search-path.  Then try searching
> > for its basename as a last resort.  Right?
> 
> I don't like it.  In particular, the part I don't like is:
> 
> +  /* If the search in solib_absolute_prefix failed, and the path name is
> +     absolute at this point, make it relative.  (openp will try and open the
> +     file according to its absolute path otherwise, which is not what we want.)
> +     Affects all subsequent searches for this solib.  */
> +  if (found_file < 0 && IS_DIR_SEPARATOR (in_pathname[0]))
> +    in_pathname++;
> +
> 
> I do understand Orjan's reasons for doing this, but it seems rather
> fragile to me.  I think that we'd be better off doing one of the
> following:
> 
>     1) Change openp()'s behavior so that it (optionally) doesn't
>        attempt to open a file (which has an absolute path).  I.e,
>        force it to only consider the paths that we pass it.
> 
>     2) Explicitly prepend solib_absolute_prefix to the path in question
>        and pass that to openp().  Or, perhaps openp() doesn't even need
>        to be called.  Perhaps we can do the job with open().

If I understand correctly, that's not what he was trying to accomplish. 
He was trying to have openp() search for the "absolute" path after each
member of solib-search-path.  Am I wrong?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Kevin Buettner]

On Nov 27,  2:29pm, Daniel Jacobowitz wrote:

> I think your patch is OK.  If we fail to find it in the absolute path,
> search for its "absolute" (without leading directory separator[s])
> path in each directory in the solib-search-path.  Then try searching
> for its basename as a last resort.  Right?

I don't like it.  In particular, the part I don't like is:

+  /* If the search in solib_absolute_prefix failed, and the path name is
+     absolute at this point, make it relative.  (openp will try and open the
+     file according to its absolute path otherwise, which is not what we want.)
+     Affects all subsequent searches for this solib.  */
+  if (found_file < 0 && IS_DIR_SEPARATOR (in_pathname[0]))
+    in_pathname++;
+

I do understand Orjan's reasons for doing this, but it seems rather
fragile to me.  I think that we'd be better off doing one of the
following:

    1) Change openp()'s behavior so that it (optionally) doesn't
       attempt to open a file (which has an absolute path).  I.e,
       force it to only consider the paths that we pass it.

    2) Explicitly prepend solib_absolute_prefix to the path in question
       and pass that to openp().  Or, perhaps openp() doesn't even need
       to be called.  Perhaps we can do the job with open().

Of these two, I like the second better.

Kevin

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Daniel Jacobowitz]

On Tue, Nov 27, 2001 at 04:36:08PM +0100, Orjan Friberg wrote:
> Daniel Jacobowitz wrote:
> > 
> > On Tue, Nov 27, 2001 at 04:03:45PM +0100, Orjan Friberg wrote:
> > >
> > > My thought was to make the path relative if the search for the absolute path failed,
> > > by simply getting rid of the leading '/'.  (It won't work with DOS based file
> > > systems, as the dir separator could be '\\', but that would be easy to add.)
> > > Needless to say, this works for me, but I'm not sure it's The Right Thing to do.
> > > (Another approach would be to change openp, but I'm sure there's a good reason for
> > > its current behaviour.)
> > 
> > I've got one concern with this.  In native debugging, we want to open
> > the absolute path BEFORE searching solib-search-path - you might have
> > dlopened() a specific optimized version of a library whose base exists
> > in /usr/lib, for instance.
> 
> I'm not sure I follow: wouldn't that be covered by solib_absolute_prefix being set to
> /usr/lib?  I mean, I haven't changed the order between searching in
> solib_absolute_prefix and solib_search_path.  Or do you mean the case where
> solib_absolute_prefix isn't set, and we end up searching for it using
> LD_LIBRARY_PATH?  Hm, maybe we should only make the path relative if we are about to
> search for the solib in solib_search_path, leaving the other cases unaffected.

That sounds a little better.  If there's a /lib/lib or a
/usr/lib/usr/lib it's their own fault.  I'm still not convinced,
though.

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.

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.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Orjan Friberg]

Daniel Jacobowitz wrote:
> 
> On Tue, Nov 27, 2001 at 04:03:45PM +0100, Orjan Friberg wrote:
> >
> > My thought was to make the path relative if the search for the absolute path failed,
> > by simply getting rid of the leading '/'.  (It won't work with DOS based file
> > systems, as the dir separator could be '\\', but that would be easy to add.)
> > Needless to say, this works for me, but I'm not sure it's The Right Thing to do.
> > (Another approach would be to change openp, but I'm sure there's a good reason for
> > its current behaviour.)
> 
> I've got one concern with this.  In native debugging, we want to open
> the absolute path BEFORE searching solib-search-path - you might have
> dlopened() a specific optimized version of a library whose base exists
> in /usr/lib, for instance.

I'm not sure I follow: wouldn't that be covered by solib_absolute_prefix being set to
/usr/lib?  I mean, I haven't changed the order between searching in
solib_absolute_prefix and solib_search_path.  Or do you mean the case where
solib_absolute_prefix isn't set, and we end up searching for it using
LD_LIBRARY_PATH?  Hm, maybe we should only make the path relative if we are about to
search for the solib in solib_search_path, leaving the other cases unaffected.

-- 
Orjan Friberg
Axis Communications AB

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Eli Zaretskii]

> Date: Tue, 27 Nov 2001 16:03:45 +0100
> From: Orjan Friberg <orjan.friberg@axis.com>
>  
> +  /* If the search in solib_absolute_prefix failed, and the path name is
> +     absolute at this point, make it relative.  (openp will try and open the
> +     file according to its absolute path otherwise, which is not what we want.)
> +     Affects all subsequent searches for this solib.  */
> +  if (found_file < 0 && IS_DIR_SEPARATOR (in_pathname[0]))
> +    in_pathname++;

This is not how one should test for an absoulte file name portably,
and incrementing in_pathname by one is not how you portably make it a
relative file name.  I suggest to use IS_ABSOLUTE_PATH for the first
and this for the second:

   while (!IS_DIR_SEPARATOR (*in_pathname++))
     ;

Please note that these portable macros are described in gdbint.texinfo
(node "Coding", subsection about portable coding).

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Eli Zaretskii]

> Date: Tue, 27 Nov 2001 16:03:45 +0100
> From: Orjan Friberg <orjan.friberg@axis.com>
>  
> +  /* If the search in solib_absolute_prefix failed, and the path name is
> +     absolute at this point, make it relative.  (openp will try and open the
> +     file according to its absolute path otherwise, which is not what we want.)
> +     Affects all subsequent searches for this solib.  */
> +  if (found_file < 0 && IS_DIR_SEPARATOR (in_pathname[0]))
> +    in_pathname++;

This is not how one should test for an absoulte file name portably,
and incrementing in_pathname by one is not how you portably make it a
relative file name.  I suggest to use IS_ABSOLUTE_PATH for the first
and this for the second:

   while (!IS_DIR_SEPARATOR (*in_pathname++))
     ;

Please note that these portable macros are described in gdbint.texinfo
(node "Coding", subsection about portable coding).

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Orjan Friberg]

Eli Zaretskii wrote:
> 
> This is not how one should test for an absoulte file name portably,
> and incrementing in_pathname by one is not how you portably make it a
> relative file name.

Yes, I know (from my original post):

> (It won't work with DOS based file
> systems, as the dir separator could be '\\', but that would be easy to add.)

Thanks for the suggestion on how to do it correctly though; I'll
incorporate it.

-- 
Orjan Friberg
Axis Communications AB

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Orjan Friberg]

Eli Zaretskii wrote:
> 
> This is not how one should test for an absoulte file name portably,
> and incrementing in_pathname by one is not how you portably make it a
> relative file name.

Yes, I know (from my original post):

> (It won't work with DOS based file
> systems, as the dir separator could be '\\', but that would be easy to add.)

Thanks for the suggestion on how to do it correctly though; I'll
incorporate it.

-- 
Orjan Friberg
Axis Communications AB

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Eli Zaretskii]

> Date: Tue, 27 Nov 2001 19:15:42 +0100
> From: Orjan Friberg <orjan.friberg@axis.com>
> 
> Eli Zaretskii wrote:
> > 
> > This is not how one should test for an absoulte file name portably,
> > and incrementing in_pathname by one is not how you portably make it a
> > relative file name.
> 
> Yes, I know (from my original post):
> 
> > (It won't work with DOS based file
> > systems, as the dir separator could be '\\', but that would be easy to add.)

I've seen that, but you only mentioned the backslash nuisance.  My
point was that there are more subtle problems: the first character of
an absolute file name doesn't have to be a slash or a backslash.

> Thanks for the suggestion on how to do it correctly though; I'll
> incorporate it.

You are welcome.

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Eli Zaretskii]

> Date: Tue, 27 Nov 2001 19:15:42 +0100
> From: Orjan Friberg <orjan.friberg@axis.com>
> 
> Eli Zaretskii wrote:
> > 
> > This is not how one should test for an absoulte file name portably,
> > and incrementing in_pathname by one is not how you portably make it a
> > relative file name.
> 
> Yes, I know (from my original post):
> 
> > (It won't work with DOS based file
> > systems, as the dir separator could be '\\', but that would be easy to add.)

I've seen that, but you only mentioned the backslash nuisance.  My
point was that there are more subtle problems: the first character of
an absolute file name doesn't have to be a slash or a backslash.

> Thanks for the suggestion on how to do it correctly though; I'll
> incorporate it.

You are welcome.

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Orjan Friberg]

Eli Zaretskii wrote:
> 
> > Date: Tue, 27 Nov 2001 19:15:42 +0100
> > From: Orjan Friberg <orjan.friberg@axis.com>
> >
> > Yes, I know (from my original post):
> >
> > > (It won't work with DOS based file
> > > systems, as the dir separator could be '\\', but that would be easy to add.)
> 
> I've seen that, but you only mentioned the backslash nuisance.  My
> point was that there are more subtle problems: the first character of
> an absolute file name doesn't have to be a slash or a backslash.

Ah yes, the drive letter thingy.  Then I didn't know ;) .

-- 
Orjan Friberg
Axis Communications AB

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Orjan Friberg]

Eli Zaretskii wrote:
> 
> > Date: Tue, 27 Nov 2001 19:15:42 +0100
> > From: Orjan Friberg <orjan.friberg@axis.com>
> >
> > Yes, I know (from my original post):
> >
> > > (It won't work with DOS based file
> > > systems, as the dir separator could be '\\', but that would be easy to add.)
> 
> I've seen that, but you only mentioned the backslash nuisance.  My
> point was that there are more subtle problems: the first character of
> an absolute file name doesn't have to be a slash or a backslash.

Ah yes, the drive letter thingy.  Then I didn't know ;) .

-- 
Orjan Friberg
Axis Communications AB

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Orjan Friberg]

Eli Zaretskii wrote:
> 
> This is not how one should test for an absoulte file name portably,
> and incrementing in_pathname by one is not how you portably make it a
> relative file name.  I suggest to use IS_ABSOLUTE_PATH for the first
> and this for the second:
> 
>    while (!IS_DIR_SEPARATOR (*in_pathname++))
>      ;

If I understand you correctly, your suggestion is:

  if (found_file < 0 && IS_ABSOLUTE_PATH (in_pathname))
    {
      while (!IS_DIR_SEPARATOR (*in_pathname++))
        ;
    }

That will only get rid of the first dir separator.
To me it seems it should be something like:

  if (found_file < 0 && IS_ABSOLUTE_PATH (in_pathname))
    {
      while (IS_DIR_SEPARATOR (*in_pathname))
        in_pathname++;
    }

(Can't use while (IS_DIR_SEPARATOR (*in_pathname++)) as it would remove the first
non-dir separator also.)

-- 
Orjan Friberg
Axis Communications AB

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Orjan Friberg]

Eli Zaretskii wrote:
> 
> This is not how one should test for an absoulte file name portably,
> and incrementing in_pathname by one is not how you portably make it a
> relative file name.  I suggest to use IS_ABSOLUTE_PATH for the first
> and this for the second:
> 
>    while (!IS_DIR_SEPARATOR (*in_pathname++))
>      ;

If I understand you correctly, your suggestion is:

  if (found_file < 0 && IS_ABSOLUTE_PATH (in_pathname))
    {
      while (!IS_DIR_SEPARATOR (*in_pathname++))
        ;
    }

That will only get rid of the first dir separator.
To me it seems it should be something like:

  if (found_file < 0 && IS_ABSOLUTE_PATH (in_pathname))
    {
      while (IS_DIR_SEPARATOR (*in_pathname))
        in_pathname++;
    }

(Can't use while (IS_DIR_SEPARATOR (*in_pathname++)) as it would remove the first
non-dir separator also.)

-- 
Orjan Friberg
Axis Communications AB

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Eli Zaretskii]

> Date: Wed, 28 Nov 2001 11:00:09 +0100
> From: Orjan Friberg <orjan.friberg@axis.com>
> > 
> >    while (!IS_DIR_SEPARATOR (*in_pathname++))
> >      ;
> 
> If I understand you correctly, your suggestion is:
> 
>   if (found_file < 0 && IS_ABSOLUTE_PATH (in_pathname))
>     {
>       while (!IS_DIR_SEPARATOR (*in_pathname++))
>         ;
>     }

Yes, that's what I suggested.

> That will only get rid of the first dir separator.

But that's what your original code did on Unix: it would test if the
first character is a slash, and if so, step over that one slash.  Did
I miss something?

> To me it seems it should be something like:
> 
>   if (found_file < 0 && IS_ABSOLUTE_PATH (in_pathname))
>     {
>       while (IS_DIR_SEPARATOR (*in_pathname))
>         in_pathname++;
>     }
> 
> (Can't use while (IS_DIR_SEPARATOR (*in_pathname++)) as it would
> remove the first non-dir separator also.)

No, I do think my code is right.  Let me explain why.

Since we are under the if clause, we _know_ that the file name begins
with either "/foo" or "d:/foo".  In the first case, IS_DIR_SEPARATOR
returns 1, so the while loop is terminated immediately, but
in_pathname was already bumped to point after the slash--that's what
your original code did.  In the second code, the loop will march over
the drive letter and the colon and terminate on the slash that
follows, and again in_pathname will be incremented by the last
iteration to point right after the slash.

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Eli Zaretskii]

> Date: Wed, 28 Nov 2001 11:00:09 +0100
> From: Orjan Friberg <orjan.friberg@axis.com>
> > 
> >    while (!IS_DIR_SEPARATOR (*in_pathname++))
> >      ;
> 
> If I understand you correctly, your suggestion is:
> 
>   if (found_file < 0 && IS_ABSOLUTE_PATH (in_pathname))
>     {
>       while (!IS_DIR_SEPARATOR (*in_pathname++))
>         ;
>     }

Yes, that's what I suggested.

> That will only get rid of the first dir separator.

But that's what your original code did on Unix: it would test if the
first character is a slash, and if so, step over that one slash.  Did
I miss something?

> To me it seems it should be something like:
> 
>   if (found_file < 0 && IS_ABSOLUTE_PATH (in_pathname))
>     {
>       while (IS_DIR_SEPARATOR (*in_pathname))
>         in_pathname++;
>     }
> 
> (Can't use while (IS_DIR_SEPARATOR (*in_pathname++)) as it would
> remove the first non-dir separator also.)

No, I do think my code is right.  Let me explain why.

Since we are under the if clause, we _know_ that the file name begins
with either "/foo" or "d:/foo".  In the first case, IS_DIR_SEPARATOR
returns 1, so the while loop is terminated immediately, but
in_pathname was already bumped to point after the slash--that's what
your original code did.  In the second code, the loop will march over
the drive letter and the colon and terminate on the slash that
follows, and again in_pathname will be incremented by the last
iteration to point right after the slash.

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Orjan Friberg]

Eli Zaretskii wrote:
> 
> > Date: Wed, 28 Nov 2001 11:00:09 +0100
> > From: Orjan Friberg <orjan.friberg@axis.com>
> 
> > That will only get rid of the first dir separator.
> 
> But that's what your original code did on Unix: it would test if the
> first character is a slash, and if so, step over that one slash.  Did
> I miss something?

No, you didn't miss anything ;) .  I forgot to explain something.

> Since we are under the if clause, we _know_ that the file name begins
> with either "/foo" or "d:/foo".  In the first case, IS_DIR_SEPARATOR
> returns 1, so the while loop is terminated immediately, but
> in_pathname was already bumped to point after the slash--that's what
> your original code did.  In the second code, the loop will march over
> the drive letter and the colon and terminate on the slash that
> follows, and again in_pathname will be incremented by the last
> iteration to point right after the slash.

I was trying to address the situation where in_pathname contains several
leading slashes; then your suggested code (and my original code also)
would terminate too early.  I guess we don't normally care about
multiple leading slashes since it's a valid path, but in this case we
need to get rid of all of them to make it a relative path.

This code should cut it:

  if (found_file < 0 && IS_ABSOLUTE_PATH (in_pathname))
    {
      /* First, get rid of any drive letters etc.  */
      while (!IS_DIR_SEPARATOR (*in_pathname))
        in_pathname++;

      /* Next, get rid of all leading dir separators.  */
      while (IS_DIR_SEPARATOR (*in_pathname))
        in_pathname++;
    }

(The first while loop could have been written like your original
suggestion, to have it consume the first dir separator also, but for
consistency I did them both in the same style.)

-- 
Orjan Friberg
Axis Communications AB

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Orjan Friberg]

Eli Zaretskii wrote:
> 
> > Date: Wed, 28 Nov 2001 11:00:09 +0100
> > From: Orjan Friberg <orjan.friberg@axis.com>
> 
> > That will only get rid of the first dir separator.
> 
> But that's what your original code did on Unix: it would test if the
> first character is a slash, and if so, step over that one slash.  Did
> I miss something?

No, you didn't miss anything ;) .  I forgot to explain something.

> Since we are under the if clause, we _know_ that the file name begins
> with either "/foo" or "d:/foo".  In the first case, IS_DIR_SEPARATOR
> returns 1, so the while loop is terminated immediately, but
> in_pathname was already bumped to point after the slash--that's what
> your original code did.  In the second code, the loop will march over
> the drive letter and the colon and terminate on the slash that
> follows, and again in_pathname will be incremented by the last
> iteration to point right after the slash.

I was trying to address the situation where in_pathname contains several
leading slashes; then your suggested code (and my original code also)
would terminate too early.  I guess we don't normally care about
multiple leading slashes since it's a valid path, but in this case we
need to get rid of all of them to make it a relative path.

This code should cut it:

  if (found_file < 0 && IS_ABSOLUTE_PATH (in_pathname))
    {
      /* First, get rid of any drive letters etc.  */
      while (!IS_DIR_SEPARATOR (*in_pathname))
        in_pathname++;

      /* Next, get rid of all leading dir separators.  */
      while (IS_DIR_SEPARATOR (*in_pathname))
        in_pathname++;
    }

(The first while loop could have been written like your original
suggestion, to have it consume the first dir separator also, but for
consistency I did them both in the same style.)

-- 
Orjan Friberg
Axis Communications AB

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Eli Zaretskii]

> Date: Wed, 28 Nov 2001 18:43:33 +0100
> From: Orjan Friberg <orjan.friberg@axis.com>
> 
> I was trying to address the situation where in_pathname contains several
> leading slashes; then your suggested code (and my original code also)
> would terminate too early.  I guess we don't normally care about
> multiple leading slashes since it's a valid path, but in this case we
> need to get rid of all of them to make it a relative path.
> 
> This code should cut it:
> 
>   if (found_file < 0 && IS_ABSOLUTE_PATH (in_pathname))
>     {
>       /* First, get rid of any drive letters etc.  */
>       while (!IS_DIR_SEPARATOR (*in_pathname))
>         in_pathname++;
> 
>       /* Next, get rid of all leading dir separators.  */
>       while (IS_DIR_SEPARATOR (*in_pathname))
>         in_pathname++;
>     }

Yes, this does what you want, AFAICS.

Thanks for explaining the issue.

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Orjan Friberg]

Here's an updated patch.  Thanks to Eli, Daniel J, and Kevin for helping out.  
Ok to commit?

2001-11-29  Orjan Friberg  <orjanf@axis.com>

	* solib.c (solib_open): Make path relative if search for absolute path
	failed.  If search for relative path in solib_search_path failed, fall
	back to search for basename only.


Index: solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.45
diff -u -p -r1.45 solib.c
--- solib.c     2001/11/01 16:17:08     1.45
+++ solib.c     2001/11/29 13:36:48
@@ -131,10 +131,33 @@ solib_open (char *in_pathname, char **fo
       found_file = open (temp_pathname, O_RDONLY, 0);
     }
 
+  /* If the search in solib_absolute_prefix failed, and the path name is
+     absolute at this point, make it relative.  (openp will try and open the
+     file according to its absolute path otherwise, which is not what we want.)
+     Affects subsequent searches for this solib.  */
+  if (found_file < 0 && IS_ABSOLUTE_PATH (in_pathname))
+    {
+      /* First, get rid of any drive letters etc.  */
+      while (!IS_DIR_SEPARATOR (*in_pathname))
+        in_pathname++;
+
+      /* Next, get rid of all leading dir separators.  */
+      while (IS_DIR_SEPARATOR (*in_pathname))
+        in_pathname++;
+    }
+  
   /* 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 not found, next search the solib_search_path (if any) for the basename
+     only (ignoring the path).  This is to allow reading solibs from a path
+     that differs from the opened path.  */
+  if (found_file < 0 && solib_search_path != NULL)
+    found_file = openp (solib_search_path, 
+                        1, lbasename (in_pathname), O_RDONLY, 0,
+                        &temp_pathname);
 
   /* If not found, next search the inferior's $PATH environment variable. */
   if (found_file < 0 && solib_search_path != NULL)

-- 
Orjan Friberg
Axis Communications AB

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Orjan Friberg]

Here's an updated patch.  Thanks to Eli, Daniel J, and Kevin for helping out.  
Ok to commit?

2001-11-29  Orjan Friberg  <orjanf@axis.com>

	* solib.c (solib_open): Make path relative if search for absolute path
	failed.  If search for relative path in solib_search_path failed, fall
	back to search for basename only.


Index: solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.45
diff -u -p -r1.45 solib.c
--- solib.c     2001/11/01 16:17:08     1.45
+++ solib.c     2001/11/29 13:36:48
@@ -131,10 +131,33 @@ solib_open (char *in_pathname, char **fo
       found_file = open (temp_pathname, O_RDONLY, 0);
     }
 
+  /* If the search in solib_absolute_prefix failed, and the path name is
+     absolute at this point, make it relative.  (openp will try and open the
+     file according to its absolute path otherwise, which is not what we want.)
+     Affects subsequent searches for this solib.  */
+  if (found_file < 0 && IS_ABSOLUTE_PATH (in_pathname))
+    {
+      /* First, get rid of any drive letters etc.  */
+      while (!IS_DIR_SEPARATOR (*in_pathname))
+        in_pathname++;
+
+      /* Next, get rid of all leading dir separators.  */
+      while (IS_DIR_SEPARATOR (*in_pathname))
+        in_pathname++;
+    }
+  
   /* 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 not found, next search the solib_search_path (if any) for the basename
+     only (ignoring the path).  This is to allow reading solibs from a path
+     that differs from the opened path.  */
+  if (found_file < 0 && solib_search_path != NULL)
+    found_file = openp (solib_search_path, 
+                        1, lbasename (in_pathname), O_RDONLY, 0,
+                        &temp_pathname);
 
   /* If not found, next search the inferior's $PATH environment variable. */
   if (found_file < 0 && solib_search_path != NULL)

-- 
Orjan Friberg
Axis Communications AB

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Kevin Buettner]

On Nov 29,  2:52pm, Orjan Friberg wrote:

> Here's an updated patch.  Thanks to Eli, Daniel J, and Kevin for helping out.  
> Ok to commit?
> 
> 2001-11-29  Orjan Friberg  <orjanf@axis.com>
> 
> 	* solib.c (solib_open): Make path relative if search for absolute path
> 	failed.  If search for relative path in solib_search_path failed, fall
> 	back to search for basename only.

Yes, approved.

Thanks,

Kevin

Re: [RFC]: Solib search (Was: Re: Cross solib support; continued)

[Orjan Friberg]

Kevin Buettner wrote:
> 
> On Nov 29,  2:52pm, Orjan Friberg wrote:
> 
> > Here's an updated patch.  Thanks to Eli, Daniel J, and Kevin for helping out.
> > Ok to commit?
> >
> > 2001-11-29  Orjan Friberg  <orjanf@axis.com>
> >
> >       * solib.c (solib_open): Make path relative if search for absolute path
> >       failed.  If search for relative path in solib_search_path failed, fall
> >       back to search for basename only.
> 
> Yes, approved.

Committed.  Thanks alot for reviewing it.

-- 
Orjan Friberg
Axis Communications AB