interesting solib-absolute-prefix problem

["Kris Warkentin" <kewarken at qnx dot com>]

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.  */