interesting solib-absolute-prefix problem

interesting solib-absolute-prefix problem

[Kris Warkentin]

Ah....good old solib_open() and finding shared libraries.

Our setup is such that even on self-hosted Neutrino, we still have
directories /x86, /mipsle, /armbe, etc. which have a full heirarchy of bin,
lib, usr/lib, etc. underneath.  We set solib-absolute-prefix to point to
these when debugging.  On a different host, it might be something like
c:/QNXsdk/target/qnx6/ppcbe but the principle is the same.  We use
solib-absolute-prefix and stuff gets found.

Now say I'm debugging a program /home/kewarken/myprog which is linked to
/home/kewarken/libmylib.so.  Given that the linker fills in
/home/kewarken/libmylib.so and this path gets passed to solib_open(), you
would think you wouldn't get a misleading error like:

 Error while mapping shared library sections:
 /home/kewarken/libmylib.so: No such file or directory.

Now it's fairly obvious why this doesn't happen: solib_open uses
solib-absolute-prefix and various other things but never actually just tries
opening the file.  The logic of this is quite apparent.  We don't want, for
example, /lib/libc.so to get opened on my Solaris system when I'm really
looking for /opt/QNXsdk/target/qnx6/shle/lib/libc.so.  That would be bad.
The problem of course is that having gdb complain that it can't find a file
which is clearly there is quite ugly.  Note that setting solib-search-path
avoids all these problems.  Not really great though.  You'd think that if
the linker says "/some/path/to/libalib.so" that it would be found.

One would think that not initializing solib-absolute-prefix when doing
native debugging would work but the problem for us is that we need to find
/x86/usr/lib/ldqnx.so (our linker) rather than /proc/boot/libc.so since our
image builder strips all the section information from binaries and gdb uses
the .dynamic section.

To make a long story short, I put an 'open() of last resort' in solib_open
right at the end where if all else fails, it tries to open the exact path it
was given.  It would seem to me that this is probably not too dangerous but
someone might be able to comment on this better than I.

cheers,

Kris

$ cvs diff -c solib.c
Index: solib.c
===================================================================
RCS file: /product/tools/gdb/gdb/solib.c,v
retrieving revision 1.8
diff -c -r1.8 solib.c
*** solib.c     17 Jun 2003 19:21:38 -0000      1.8
--- solib.c     3 Dec 2003 19:25:24 -0000
***************
*** 104,109 ****
--- 104,110 ----
    int found_file = -1;
    char *temp_pathname = NULL;
    char *p = in_pathname;
+   char *orig = in_pathname;

    while (*p && !IS_DIR_SEPARATOR (*p))
      p++;
***************
*** 175,180 ****
--- 176,185 ----
    if (found_file < 0)
      found_file = openp (get_in_environ (inferior_environ,
"LD_LIBRARY_PATH"),
                        1, in_pathname, O_RDONLY, 0, &temp_pathname);
+
+   /* If all else fails, at least try the original without any window
dressing.
  */
+   if (found_file < 0 && (found_file = open (orig, O_RDONLY, 0)) > -1)
+     temp_pathname = orig;

    /* Done.  If not found, tough luck.  Return found_file and
       (optionally) found_pathname.  */

Re: interesting solib-absolute-prefix problem

[Kevin Buettner]

On Dec 3,  2:48pm, Kris Warkentin wrote:

> One would think that not initializing solib-absolute-prefix when doing
> native debugging would work but the problem for us is that we need to find
> /x86/usr/lib/ldqnx.so (our linker) rather than /proc/boot/libc.so since our
> image builder strips all the section information from binaries and gdb uses
> the .dynamic section.
> 
> To make a long story short, I put an 'open() of last resort' in solib_open
> right at the end where if all else fails, it tries to open the exact path it
> was given.  It would seem to me that this is probably not too dangerous but
> someone might be able to comment on this better than I.

I don't really like this patch.  If someone sets solib-absolute-prefix
incorrectly - a quite common occurrence, I've found - we don't want to
inadverently open the host's /lib/libc.so (or the like).  In this case,
it's preferable for gdb to print an error message.

It would, perhaps, be less misleading if GDB were to list the paths
that it tried (and failed) to open.

It's still not clear to me why you need solib-absolute-prefix set when
doing native debugging.  (You explained it above, but I don't understand
your environment well enough to comprehend the explanation.)

Kevin

Re: interesting solib-absolute-prefix problem

[Kris Warkentin]

> > To make a long story short, I put an 'open() of last resort' in
solib_open
> > right at the end where if all else fails, it tries to open the exact
path it
> > was given.  It would seem to me that this is probably not too dangerous
but
> > someone might be able to comment on this better than I.
>
> I don't really like this patch.  If someone sets solib-absolute-prefix
> incorrectly - a quite common occurrence, I've found - we don't want to
> inadverently open the host's /lib/libc.so (or the like).  In this case,
> it's preferable for gdb to print an error message.

I'm not super fond of it either.  I was actually tempted to put a warning in
that bit of code to tell the user that it found the library there and that
it might not be what they wanted.  Note that in our case, we actually
initialize solib-absolute-prefix within the code based on our environment.

> It would, perhaps, be less misleading if GDB were to list the paths
> that it tried (and failed) to open.

Perhaps.  The net result is still that it had the exact path the the lib and
still couldn't find it.

> It's still not clear to me why you need solib-absolute-prefix set when
> doing native debugging.  (You explained it above, but I don't understand
> your environment well enough to comprehend the explanation.)

It's a bit screwy....you'll probably just have to trust me on it.  If it
makes you feel better, I can give an example of the problem when doing
remote debugging.  Say I'm in my homedir on a cygwin machine.  I export a
CIFS dir /home/kewarken/foo where I build my app.  My remote machines
homedir has foo mounted.  So /home/kewarken/foo/libmylib.so is exactly the
same path on the local and the remote.  I've got solib-absolute-prefix set
to find my system libs but I would hope that gdb would find libmylib.so
properly because its location is the same on the host and target.  As it
stands, it doesn't.

Would printing something like: "Warning: opening <path_to_lib> without using
solib-absolute-prefix.  You may need to set solib-search-path." make it a
little better?  I could also test for solib_absolute_prefix like so:

+   if (solib_absolute_prefix != NULL && found_file < 0 && (found_file =
open (orig, O_RDONLY, 0)) > -1)
+     temp_pathname = orig;

It seems to me that if we accidentally opened up the wrong libc.so, for
example, we would have some fairly catastrophic failure anyway.  You'd have
to have a pretty seriously misconfigured system for that to happen,
especially since this last ditch check happens after all other search paths
are used.

cheers,

Kris

Re: interesting solib-absolute-prefix problem

[Daniel Jacobowitz]

On Wed, Dec 03, 2003 at 04:21:06PM -0500, Kris Warkentin wrote:
> It's a bit screwy....you'll probably just have to trust me on it.  If it
> makes you feel better, I can give an example of the problem when doing
> remote debugging.  Say I'm in my homedir on a cygwin machine.  I export a
> CIFS dir /home/kewarken/foo where I build my app.  My remote machines
> homedir has foo mounted.  So /home/kewarken/foo/libmylib.so is exactly the
> same path on the local and the remote.  I've got solib-absolute-prefix set
> to find my system libs but I would hope that gdb would find libmylib.so
> properly because its location is the same on the host and target.  As it
> stands, it doesn't.
> 
> Would printing something like: "Warning: opening <path_to_lib> without using
> solib-absolute-prefix.  You may need to set solib-search-path." make it a
> little better?  I could also test for solib_absolute_prefix like so:
> 
> +   if (solib_absolute_prefix != NULL && found_file < 0 && (found_file =
> open (orig, O_RDONLY, 0)) > -1)
> +     temp_pathname = orig;

I've got to agree with Kevin - let's really not go down this path.

> It seems to me that if we accidentally opened up the wrong libc.so, for
> example, we would have some fairly catastrophic failure anyway.  You'd have

Yes, we do.  Usually, it involves GDB segfaulting.  That's why I don't
want us to do this :)

> to have a pretty seriously misconfigured system for that to happen,
> especially since this last ditch check happens after all other search paths
> are used.

For your users, since you autoset solib-absolute-prefix, yes you'd have
to have a pretty seriously misconfigured system.  For my users (at
MontaVista), the same thing, since we do something similar for cross
debugging.  For the average person who rolls a toolchain themselves,
however, this is an extremely common problem.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: interesting solib-absolute-prefix problem

[Kris Warkentin]

> > to have a pretty seriously misconfigured system for that to happen,
> > especially since this last ditch check happens after all other search
paths
> > are used.
>
> For your users, since you autoset solib-absolute-prefix, yes you'd have
> to have a pretty seriously misconfigured system.  For my users (at
> MontaVista), the same thing, since we do something similar for cross
> debugging.  For the average person who rolls a toolchain themselves,
> however, this is an extremely common problem.

I'm thinking I might be able to cheat in our backend to work around this.
It's a bit of a nuisance since it seems to be popping up all over.  I wish I
could just avoid initializing solib-abs-pref in the self hosted case.
Grr...stupid OS guys.  ;-)

Kris

Re: interesting solib-absolute-prefix problem

[Kris Warkentin]

Actually, I just discovered a way to work around it in our back end
TARGET_FIND_AND_OPEN_SOLIB.  The fact that I KNOW we always have
solib-absolute-prefix initialized means that I can cheat a bit.

As far as setting it to "/", that doesn't work self-hosted because we need
to specifically find something under /x86/usr/lib.  Unfortunately I don't
get to decide the layout, I just have to work with it.  Either way, now I
can keep the kludgey stuff in our own backend where it won't hurt anyone.
Thanks for all the help.

cheers,

Kris

----- Original Message ----- 
From: "Michael Elizabeth Chastain" <mec.gnu@mindspring.com>
To: <gdb@sources.redhat.com>; <kevinb@redhat.com>; <kewarken@qnx.com>
Sent: Wednesday, December 03, 2003 5:33 PM
Subject: Re: interesting solib-absolute-prefix problem


> Ummm, hit me with a clue-stick if I am missing the point,
> but it looks like Kris's desire is to have solib-absolute-prefix=""
> be a meaningful value, but gdb already uses that for something else.
> And we don't want to get those semantics by accident.
>
> Can you kludge it by setting solib-absolute-prefix="/."?
>
> I agree with Kevin, I don't like kludges where gdb says
> "might as well try this".  The risk is that it will bogusly
> succeed on some other system.
>
> Michael C
>

Re: interesting solib-absolute-prefix problem

[Michael Elizabeth Chastain]

Ummm, hit me with a clue-stick if I am missing the point,
but it looks like Kris's desire is to have solib-absolute-prefix=""
be a meaningful value, but gdb already uses that for something else.
And we don't want to get those semantics by accident.

Can you kludge it by setting solib-absolute-prefix="/."?

I agree with Kevin, I don't like kludges where gdb says
"might as well try this".  The risk is that it will bogusly
succeed on some other system.

Michael C