This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

From: Daniel Jacobowitz <drow@mvista.com>
To: Kevin Buettner <kevinb@redhat.com>
Cc: Andrew Cagney <ac131313@ges.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:55:18 -0400

 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]