Re: solib search algorithm for cross-gdb

[Paul Koning <pkoning@equallogic.com>]

>>>>> "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