solib search algorithm for cross-gdb

solib search algorithm for cross-gdb

[Paul Koning]

Currently, the shared library search in solib.c first tries to use the
shared lib filename as given (if solib-absolute-prefix isn't set).

That's exactly right for a native gdb, but it is in general the wrong
answer for a cross-gdb.  If I'm debugging a mips box, or analyzing a
mips corefile, resolving shared lib symbols from intel shared libs in
my /usr/lib is the wrong thing.

.gdbinit helps, but not everyone remembers to do this right every
time.

I was thinking about having the case of "use the filename exactly as
supplied" in solib.c be used only in native gdb.  That seems to
require adding stuff in configure and config.in to tell a native from
a cross build.

I could submit this patch if it sounds like a good feature (otherwise
I'll probably keep it as a private change).  Comments?  Better ways to
do this?

      paul

Re: solib search algorithm for cross-gdb

[Daniel Jacobowitz]

On Wed, Aug 03, 2005 at 09:38:18AM -0400, Paul Koning wrote:
> Currently, the shared library search in solib.c first tries to use the
> shared lib filename as given (if solib-absolute-prefix isn't set).
> 
> That's exactly right for a native gdb, but it is in general the wrong
> answer for a cross-gdb.  If I'm debugging a mips box, or analyzing a
> mips corefile, resolving shared lib symbols from intel shared libs in
> my /usr/lib is the wrong thing.
> 
> .gdbinit helps, but not everyone remembers to do this right every
> time.
> 
> I was thinking about having the case of "use the filename exactly as
> supplied" in solib.c be used only in native gdb.  That seems to
> require adding stuff in configure and config.in to tell a native from
> a cross build.
> 
> I could submit this patch if it sounds like a good feature (otherwise
> I'll probably keep it as a private change).  Comments?  Better ways to
> do this?

There's an argument that this should be based primarily on the target. 
Using the native files is generally right for target "child"; generally
wrong (though not necessarily) for target "remote"; and generally right
for target "core" iff this is a native GDB.

I don't know if that's worth implementing.  I'm inclined to say that
your suggestion is progress, at least.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: solib search algorithm for cross-gdb

[Kris Warkentin]

Daniel Jacobowitz wrote:

>On Wed, Aug 03, 2005 at 09:38:18AM -0400, Paul Koning wrote:
>  
>
>>Currently, the shared library search in solib.c first tries to use the
>>shared lib filename as given (if solib-absolute-prefix isn't set).
>>
>>That's exactly right for a native gdb, but it is in general the wrong
>>answer for a cross-gdb.  If I'm debugging a mips box, or analyzing a
>>mips corefile, resolving shared lib symbols from intel shared libs in
>>my /usr/lib is the wrong thing.
>>
>>.gdbinit helps, but not everyone remembers to do this right every
>>time.
>>
>>I was thinking about having the case of "use the filename exactly as
>>supplied" in solib.c be used only in native gdb.  That seems to
>>require adding stuff in configure and config.in to tell a native from
>>a cross build.
>>
>>I could submit this patch if it sounds like a good feature (otherwise
>>I'll probably keep it as a private change).  Comments?  Better ways to
>>do this?
>>    
>>
>
>There's an argument that this should be based primarily on the target. 
>Using the native files is generally right for target "child"; generally
>wrong (though not necessarily) for target "remote"; and generally right
>for target "core" iff this is a native GDB.
>
>I don't know if that's worth implementing.  I'm inclined to say that
>your suggestion is progress, at least.
>

There's also the argument that it's almost never correct to be cross 
debugging _without_ solib-absolute-prefix set.  I had put in the 
TARGET_SO_FIND_AND_OPEN_SOLIB hook to give targets custom ways of 
finding their own stuff but I put it after the check for the literal 
path so it would play nicely with native debugging.

A really clever fix would be to check the architecture of found solibs 
and discard them and keep searching if it doesn't match (printing a 
warning perhaps).  Of course, that could still get the wrong library...  
Almost impossible to guarantee that you never get the wrong lib I 
think.  Fools are too ingenious. ;-)

cheers,

Kris

-- 
Stay up-to-date on all the QNX news!  Register at
http://www.qnx.com/news/forms/newsletter.html to
receive our newsletter.

Re: solib search algorithm for cross-gdb

[Mark Kettenis]

   Date: Wed, 3 Aug 2005 13:06:18 -0400
   From: Daniel Jacobowitz <drow@false.org>

   On Wed, Aug 03, 2005 at 09:38:18AM -0400, Paul Koning wrote:
   > Currently, the shared library search in solib.c first tries to use the
   > shared lib filename as given (if solib-absolute-prefix isn't set).
   > 
   > That's exactly right for a native gdb, but it is in general the wrong
   > answer for a cross-gdb.  If I'm debugging a mips box, or analyzing a
   > mips corefile, resolving shared lib symbols from intel shared libs in
   > my /usr/lib is the wrong thing.
   > 
   > .gdbinit helps, but not everyone remembers to do this right every
   > time.
   > 
   > I was thinking about having the case of "use the filename exactly as
   > supplied" in solib.c be used only in native gdb.  That seems to
   > require adding stuff in configure and config.in to tell a native from
   > a cross build.
   > 
   > I could submit this patch if it sounds like a good feature (otherwise
   > I'll probably keep it as a private change).  Comments?  Better ways to
   > do this?

   There's an argument that this should be based primarily on the target. 
   Using the native files is generally right for target "child"; generally
   wrong (though not necessarily) for target "remote"; and generally right
   for target "core" iff this is a native GDB.

Indeed.  What's important to really that even a native gdb can be used
for cross-debugging.  Therefore, it's probably a better idea to
determine "nativeness" at run time, by comparing the architecture and
OS/ABI to the system gdb is running on.

Incidentally, at least for POSIX systems, it seems that we generally
have a tree rooted somewhare.  I think the architecture vector should
describe the layout of that tree for a certain OS/ABI whereas the root
of that tree would be determined by some heuristic based on the target
(child, remote, core) and nativeness.  Obviously for native child and
core the root would be /.  For remote we should probably default to
whatever was specified using --with-sysroot when gdb was configured.

   I don't know if that's worth implementing.  I'm inclined to say that
   your suggestion is progress, at least.

Hmm.  I get the feeling we have been tweaking things too much already
in the past.  I'd really prefer someone making a well though-out
design and implementing things properly.

Mark

Re: solib search algorithm for cross-gdb

[Daniel Jacobowitz]

On Wed, Aug 03, 2005 at 09:15:04PM +0200, Mark Kettenis wrote:
> Indeed.  What's important to really that even a native gdb can be used
> for cross-debugging.  Therefore, it's probably a better idea to
> determine "nativeness" at run time, by comparing the architecture and
> OS/ABI to the system gdb is running on.

I don't see how that helps?  Nativeness is not the most important
factor here.  In fact, it's not even particularly important; a MIPS64
GDB doesn't have to care which ABI it was compiled for or which
architecture the debuggee was compiled for (well, except for
thread_db).

> (child, remote, core) and nativeness.  Obviously for native child and
> core the root would be /.  For remote we should probably default to
> whatever was specified using --with-sysroot when gdb was configured.

No, --with-sysroot should be honored no matter what the target is.  It
should definitely be honored for core.  It should be honored for
native, too - you can be debugging in a chroot relative to GDB.

>    I don't know if that's worth implementing.  I'm inclined to say that
>    your suggestion is progress, at least.
> 
> Hmm.  I get the feeling we have been tweaking things too much already
> in the past.  I'd really prefer someone making a well though-out
> design and implementing things properly.

Since no one has ever come up with such a design, I'm keeping my hopes
in check...

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: solib search algorithm for cross-gdb

[Paul Koning]

When I said "cross-gdb" I was thinking about host != target -- for
example an Intel host and a MIPS target.  Using the literal library
path can't possibly be right in that case.

Daniel suggests some other cases that are more dynamic -- host ==
target but we're doing remote debugging.

Right now we have TARGET_SO_FIND_AND_OPEN_SOLIB as a way for the
target specific code to add another way to find libraries, but we
don't have any way for any component to subtract ways, which is what I
need here.

As for the tree root or tree shape being in the architecture vector,
I'm not sure that works.  The issue isn't the target architecture
itself, but rather that the target and the host are different.  I
didn't think that the architecture vector expresses that.  (Possibly
my confusion -- I'm still learning gdb internals...)

Ok, I hear some encouraging notions and some helpful suggestions --
I'll see about concocting a proposal.

     paul

Re: solib search algorithm for cross-gdb

[Kris Warkentin]

Paul Koning wrote:

>When I said "cross-gdb" I was thinking about host != target -- for
>example an Intel host and a MIPS target.  Using the literal library
>path can't possibly be right in that case.
>
>Daniel suggests some other cases that are more dynamic -- host ==
>target but we're doing remote debugging.
>
>Right now we have TARGET_SO_FIND_AND_OPEN_SOLIB as a way for the
>target specific code to add another way to find libraries, but we
>don't have any way for any component to subtract ways, which is what I
>need here.
>

Setting solib-absolute-prefix is a the way to subtract searching from 
the root since it either searches <abspath> or 
<solib-abs-pref>/<abspath>, not both.  Don't know if it's practical for 
you but we explicitly set solib-absolute-prefix in our init functions so 
we never have to worry about accidentally getting /usr/lib/somelib.so 
instead of $SDK_ROOT/usr/lib/somelib.so.

cheers,

Kris

Re: solib search algorithm for cross-gdb

[Paul Koning]

>>>>> "Kris" == Kris Warkentin <kewarken@qnx.com> writes:

 Kris> Paul Koning wrote:
 >> When I said "cross-gdb" I was thinking about host != target -- for
 >> example an Intel host and a MIPS target.  Using the literal
 >> library path can't possibly be right in that case.
 >> 
 >> Daniel suggests some other cases that are more dynamic -- host ==
 >> target but we're doing remote debugging.
 >> 
 >> Right now we have TARGET_SO_FIND_AND_OPEN_SOLIB as a way for the
 >> target specific code to add another way to find libraries, but we
 >> don't have any way for any component to subtract ways, which is
 >> what I need here.
 >> 

 Kris> Setting solib-absolute-prefix is a the way to subtract
 Kris> searching from the root since it either searches <abspath> or
 Kris> <solib-abs-pref>/<abspath>, not both.  Don't know if it's
 Kris> practical for you but we explicitly set solib-absolute-prefix
 Kris> in our init functions so we never have to worry about
 Kris> accidentally getting /usr/lib/somelib.so instead of
 Kris> $SDK_ROOT/usr/lib/somelib.so.

I can't easily do that because each of our developers builds test
builds in his own sandbox, so there is no single right value.  Also,
it isn't really an issue of one specific target system, but rather the
fact that a null solib-absolute-prefix is just not meaningful if the
host and target architectures are different.  (And by "architectures"
I don't mean mips32 vs. mips64, I mean intel vs. mips or linux
vs. netbsd.)  

So the point is that the alternative currently used when
solib-absolute-prefix is null is sensible only in native runs, not
cross-debug.  (And, debatably, for native ones not even all the time,
e.g., "target remote".)  It's that alternative I want to get rid of,
conditionally.

    paul