This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb/633: fully qualified pathnames in solib_map_sections() and remote debugging
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