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

[Andrew Cagney <ac131313 at ges dot redhat dot com>]

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

From: Andrew Cagney <ac131313@ges.redhat.com>
To: 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 11:07:06 -0400

 > 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.
 
 Adding a local/remote test is going to be easier.  Having the code 
 written local/remote independant might be better long term (but runs the 
 risk of making things unnecessarily complex).
 
 enjoy,
 Andrew