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

Daniel Jacobowitz
2002-08-12T15:55:05Z

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