Dave Anglin brought this problem to my attention -

Sometimes gdb does not properly relocate symbols in shared objects, 
leading to wrong backtraces and all sorts of problems. The problem seems 
to be that the SOM solib code builds section offsets by comparing object 
filenames between objfile->name so so_list->so_name, and because the two 
filenames could have gone through different types of postprocessing, 
they can differ subtly that makes the matching fail.

In the case I debugged, gdb was comparing
/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/libjava/.libs/libgcj.sl.7
against
/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs/libgcj.sl.7

The attached patch changes the logic so that only the last component in 
the filename is compared. This of course assumes that you have not 
linked two shared objects with the same filename (hopefully not likely). 
This is not very robust either, but I think this is better than what we 
have before.

I notice that most of the solib variants do not need to do this type of 
processing; unfortunately I haven't figured out a better way to handle 
the SOM case. Perhaps somebody more familiar with the solib code/SOM can 
comment?

Meanwhile, is this patch ok?

randolph