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

[Kevin Buettner <kevinb at redhat dot com>]

The following reply was made to PR gdb/633; it has been noted by GNATS.

From: Kevin Buettner <kevinb@redhat.com>
To: Andrew Cagney <ac131313@ges.redhat.com>,
   Daniel Jacobowitz <drow@mvista.com>
Cc: Kevin Buettner <kevinb@redhat.com>, jorma.laaksonen@hut.fi,
   gdb-gnats@sources.redhat.com, gdb@sources.redhat.com
Subject: Re: gdb/633: fully qualified pathnames in solib_map_sections() and remote debugging
Date: Mon, 12 Aug 2002 08:48:49 -0700

 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.
 
 > Adding a local/remote test is going to be easier.
 
 Do we already have such a test?
 
 Kevin