This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]