Re: gdb/633: fully qualified pathnames in solib_map_sections() and remote debugging

[Daniel Jacobowitz <drow@mvista.com>]

On Mon, Aug 12, 2002 at 08:48:49AM -0700, Kevin Buettner wrote:
> On Aug 12, 11:07am, Andrew Cagney wrote:
> 
> > > This leaves only the question of "how".  I don't want to change the
> > >> >behavior for a native debugger using the remote protocol; just for
> > >> >non-native debuggers.  How should I check for this?  Using configury to
> > >> >do it seems contrary to the direction gdbarch is going (i.e. a both
> > >> >native and cross debugger in one binary).
> > > 
> > >> 
> > >> This is a target environment thing?  So why not ask the target:
> > >> 
> > >> target_getenv()
> > >> 	-> qGetenv:<STRING>
> > >> 	<- value
> > > 
> > > 
> > > No (although I will get back to qGetenv later... :).  We're discussing
> > > the behavior of the function solib.c:solib_open.  It should vary
> > > depending on whether the current target is native or not, and I don't
> > > know how to figure that out correctly.
> > 
> > There are two approaches:  have solib_open() test for a local/remote 
> > target; or, add methods to the target vector that allow solib_open() to 
> > be written independant of the target.
> 
> At the moment, I like the first approach better because it's simpler.
> I'd prefer that we wait on the more complicated approach until a need
> is demonstrated for the additional complexity.

I agree.  But as I said above, I don't want to make this decision based
on local/remote.  An i386-pc-linux-gnu debugger using gdbserver will
default to looking in the system libraries right now; that's correct, I
think.

I don't feel all that certain on this point, however.

> > Adding a local/remote test is going to be easier.
> 
> Do we already have such a test?
> 
> Kevin
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer