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

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

[Daniel Jacobowitz]

On Tue, Aug 06, 2002 at 10:06:34AM -0000, jorma.laaksonen@hut.fi wrote:
> 
> >Number:         633
> >Category:       gdb
> >Synopsis:       fully qualified pathnames in solib_map_sections() and remote debugging
> >Confidential:   no
> >Severity:       non-critical
> >Priority:       medium
> >Responsible:    unassigned
> >State:          open
> >Class:          sw-bug
> >Submitter-Id:   net
> >Arrival-Date:   Tue Aug 06 03:08:01 PDT 2002
> >Closed-Date:
> >Last-Modified:
> >Originator:     jorma.laaksonen@hut.fi
> >Release:        gdb-5.2
> >Organization:
> >Environment:
> --host=i686-pc-linux-gnu --target=arm-linux
> >Description:
> When debugging remotely an application that runs
> in another type of platform, solib_map_sections() of solib.c gets called with fully qualified pathnames
> that are correct in the target system but not necessarily
> in the host system.  Or, the host system's solib versions
> are of incorrect file format for the cross-target gdb.
> 
> When such a solib doesn't exist in host's filesystem,
> a loop of errors like
> 
> > Error while mapping shared library sections:
> > /usr/lib/libxxx.so.1: No such file or directory.
> 
> is entered.
> >How-To-Repeat:
> 
> >Fix:
> Add a variable that specifies search path for solibs
> while debugging remotely ???

There already is one :)  Two in fact.  The normal solution to this is
to set solib-absolute-prefix to point at an image of the target
filesystem.

   GLOBAL FUNCTION

   solib_open -- Find a shared library file and open it.

   SYNOPSIS

   int solib_open (char *in_patname, char **found_pathname);

   DESCRIPTION

   Global variable SOLIB_ABSOLUTE_PREFIX is used as a prefix directory
   to search for shared libraries if they have an absolute path.

   Global variable SOLIB_SEARCH_PATH is used as a prefix directory
   (or set of directories, as in LD_LIBRARY_PATH) to search for all
   shared libraries if not found in SOLIB_ABSOLUTE_PREFIX.

   Search order:
   * If path is absolute, look in SOLIB_ABSOLUTE_PREFIX.
   * If path is absolute or relative, look for it literally (unmodified).
   * Look in SOLIB_SEARCH_PATH.
   * Look in inferior's $PATH.
   * Look in inferior's $LD_LIBRARY_PATH.


I think the search order needs some revision though:
 - A cross debugger should not search $PATH or $LD_LIBRARY_PATH
 - A cross debugger may, or may not, want to look for the unmodified
path; I suspect that we only want to look for unmodified relative
paths, not unmodified absolute ones.

With those changes you would have to explicitly specify the path to
DSOs in a cross debugger via solib-absolute-prefix and
solib-search-path, and GDB would stop picking up the host libpthread.so
and making gdbserver segfault...  any comments from the list?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

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

[Kevin Buettner]

On Aug 6,  9:20am, Daniel Jacobowitz wrote:

>    Global variable SOLIB_ABSOLUTE_PREFIX is used as a prefix directory
>    to search for shared libraries if they have an absolute path.
> 
>    Global variable SOLIB_SEARCH_PATH is used as a prefix directory
>    (or set of directories, as in LD_LIBRARY_PATH) to search for all
>    shared libraries if not found in SOLIB_ABSOLUTE_PREFIX.
> 
>    Search order:
>    * If path is absolute, look in SOLIB_ABSOLUTE_PREFIX.
>    * If path is absolute or relative, look for it literally (unmodified).
>    * Look in SOLIB_SEARCH_PATH.
>    * Look in inferior's $PATH.
>    * Look in inferior's $LD_LIBRARY_PATH.
> 
> 
> I think the search order needs some revision though:
>  - A cross debugger should not search $PATH or $LD_LIBRARY_PATH

I agree with this.

>  - A cross debugger may, or may not, want to look for the unmodified
> path; I suspect that we only want to look for unmodified relative
> paths, not unmodified absolute ones.

I agree regarding absolute paths.

For relative paths, I'm not convinced that it's all that useful to
look at the unmodified path.  (Doing so requires that you have your
cwd set correctly, right?)

> With those changes you would have to explicitly specify the path to
> DSOs in a cross debugger via solib-absolute-prefix and
> solib-search-path,

I think this would be good...

> and GDB would stop picking up the host libpthread.so
> and making gdbserver segfault...

...and this too!

Kevin

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

[Daniel Jacobowitz]

On Fri, Aug 09, 2002 at 04:12:06PM -0700, Kevin Buettner wrote:
> On Aug 6,  9:20am, Daniel Jacobowitz wrote:
> 
> >    Global variable SOLIB_ABSOLUTE_PREFIX is used as a prefix directory
> >    to search for shared libraries if they have an absolute path.
> > 
> >    Global variable SOLIB_SEARCH_PATH is used as a prefix directory
> >    (or set of directories, as in LD_LIBRARY_PATH) to search for all
> >    shared libraries if not found in SOLIB_ABSOLUTE_PREFIX.
> > 
> >    Search order:
> >    * If path is absolute, look in SOLIB_ABSOLUTE_PREFIX.
> >    * If path is absolute or relative, look for it literally (unmodified).
> >    * Look in SOLIB_SEARCH_PATH.
> >    * Look in inferior's $PATH.
> >    * Look in inferior's $LD_LIBRARY_PATH.
> > 
> > 
> > I think the search order needs some revision though:
> >  - A cross debugger should not search $PATH or $LD_LIBRARY_PATH
> 
> I agree with this.
> 
> >  - A cross debugger may, or may not, want to look for the unmodified
> > path; I suspect that we only want to look for unmodified relative
> > paths, not unmodified absolute ones.
> 
> I agree regarding absolute paths.
> 
> For relative paths, I'm not convinced that it's all that useful to
> look at the unmodified path.  (Doing so requires that you have your
> cwd set correctly, right?)

Yes; I think that's not too unreasonable, though.  I can go either way
on this one; I believe it never comes up in GNU/Linux since the linker
fills in the full path in the link map.  Not 100% sure of that,
however.

> > With those changes you would have to explicitly specify the path to
> > DSOs in a cross debugger via solib-absolute-prefix and
> > solib-search-path,
> 
> I think this would be good...
> 
> > and GDB would stop picking up the host libpthread.so
> > and making gdbserver segfault...
> 
> ...and this too!

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).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Jorma Laaksonen]

Daniel Jacobowitz <drow@mvista.com> writes:

> > >    Global variable SOLIB_ABSOLUTE_PREFIX is used as a prefix directory
> > >    to search for shared libraries if they have an absolute path.
> > > 
> > >    Global variable SOLIB_SEARCH_PATH is used as a prefix directory
> > >    (or set of directories, as in LD_LIBRARY_PATH) to search for all
> > >    shared libraries if not found in SOLIB_ABSOLUTE_PREFIX.
> > > 
> > >    Search order:
> > >    * If path is absolute, look in SOLIB_ABSOLUTE_PREFIX.
> > >    * If path is absolute or relative, look for it literally (unmodified).
> > >    * Look in SOLIB_SEARCH_PATH.
> > >    * Look in inferior's $PATH.
> > >    * Look in inferior's $LD_LIBRARY_PATH.
> > > 
> > ...

Thank you very much for giving thoughs to this issue.  I have two additional
points to add:

1) It would be most useful if gdb could check that the remote and local
solibs are equal, eg. that their versions, checksums or other identifiers
or the memory mapping locations such as reported by ldd are the same.
Otherwise, the host cannot know what really is going on in the target.

2) The texinfo documentation should be updated to include these vaariables.
In the first place, I was reading info pages and therefore concluded
that the problem had not been addressed before.  Only after your reply
I checked "help show" within gdb.

Yours,

Jorma Laaksonen


-- 
Jorma Laaksonen                                 email: jorma.laaksonen@hut.fi
Dr. of Science in Technology, Docent            http://www.cis.hut.fi/jorma/
Laboratory of Computer and Information Science  tel. +358-9-4513269
Helsinki University of Technology               fax. +358-9-4513277
P.O.Box 5400, Fin-02015 HUT, Finland            mob. +358-50-3058719

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

[Andrew Cagney]

>> > I think the search order needs some revision though:
>> >  - A cross debugger should not search $PATH or $LD_LIBRARY_PATH
> 
>> 
>> I agree with this.
>> 
> 
>> >  - A cross debugger may, or may not, want to look for the unmodified
>> > path; I suspect that we only want to look for unmodified relative
>> > paths, not unmodified absolute ones.
> 
>> 
>> I agree regarding absolute paths.
>> 
>> For relative paths, I'm not convinced that it's all that useful to
>> look at the unmodified path.  (Doing so requires that you have your
>> cwd set correctly, right?)
> 
> 
> Yes; I think that's not too unreasonable, though.  I can go either way
> on this one; I believe it never comes up in GNU/Linux since the linker
> fills in the full path in the link map.  Not 100% sure of that,
> however.
> 
> 
>> > With those changes you would have to explicitly specify the path to
>> > DSOs in a cross debugger via solib-absolute-prefix and
>> > solib-search-path,
> 
>> 
>> I think this would be good...
>> 
> 
>> > and GDB would stop picking up the host libpthread.so
>> > and making gdbserver segfault...
> 
>> 
>> ...and this too!
> 
> 
> 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

Andrew

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

[Daniel Jacobowitz]

On Mon, Aug 12, 2002 at 10:28:33AM -0400, Andrew Cagney wrote:
> 
> >>> I think the search order needs some revision though:
> >>>  - A cross debugger should not search $PATH or $LD_LIBRARY_PATH
> >
> >>
> >>I agree with this.
> >>
> >
> >>>  - A cross debugger may, or may not, want to look for the unmodified
> >>> path; I suspect that we only want to look for unmodified relative
> >>> paths, not unmodified absolute ones.
> >
> >>
> >>I agree regarding absolute paths.
> >>
> >>For relative paths, I'm not convinced that it's all that useful to
> >>look at the unmodified path.  (Doing so requires that you have your
> >>cwd set correctly, right?)
> >
> >
> >Yes; I think that's not too unreasonable, though.  I can go either way
> >on this one; I believe it never comes up in GNU/Linux since the linker
> >fills in the full path in the link map.  Not 100% sure of that,
> >however.
> >
> >
> >>> With those changes you would have to explicitly specify the path to
> >>> DSOs in a cross debugger via solib-absolute-prefix and
> >>> solib-search-path,
> >
> >>
> >>I think this would be good...
> >>
> >
> >>> and GDB would stop picking up the host libpthread.so
> >>> and making gdbserver segfault...
> >
> >>
> >>...and this too!
> >
> >
> >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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Andrew Cagney]

> 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

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

[Kevin Buettner]

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

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

[Daniel Jacobowitz]

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

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

[Andrew Cagney]

> 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?

Well, looking at some finally dead hacks, ....

int
remote_Z_write_wp_packet_supported_p (void)
{
   struct remote_state *rs = get_remote_state ();
   /* Don't even think about it if the remote target isn't selected.  */
   /* FIXME: cagney/2002-05-19: This shouldn't be necessary - the
      WATCHPOINT methods should be in the target vector.  Ulgh!  */
   if (target_shortname == NULL
       || strcmp (target_shortname, "remote") != 0)
     return 0;

notice that the problem it was trying to avoid was with ``target sim''. 
  So in the above the question is no longer local/remote but local VS 
remote VS sim VS ....

Andrew

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

[Kevin Buettner]

On Aug 12, 11:55am, Daniel Jacobowitz wrote:

> > > 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'm wondering how frequently this particular scenario occurs.  If it
occurs relatively infrequently, I think it'd be better to force the
user to set solib-absolute-prefix and/or solib-search-path.  It certainly
seems safer than incorrectly using the host's environment variables.

Usually, when I do the above, I'm running the debug agent in a chroot
environment which has different libraries.  For a quick and dirty test
of the debug agent though, I'll frequently just run it on the host in
which case using the host's libraries is correct.

As noted earlier in this thread (and by yourself on at least one
occassion), one of the things which we sorely need is a mechanism to
check to see if gdb has loaded the correct shared object.

Kevin

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

[Daniel Jacobowitz]

On Mon, Aug 12, 2002 at 09:20:24AM -0700, Kevin Buettner wrote:
> On Aug 12, 11:55am, Daniel Jacobowitz wrote:
> 
> > > > 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'm wondering how frequently this particular scenario occurs.  If it
> occurs relatively infrequently, I think it'd be better to force the
> user to set solib-absolute-prefix and/or solib-search-path.  It certainly
> seems safer than incorrectly using the host's environment variables.
> 
> Usually, when I do the above, I'm running the debug agent in a chroot
> environment which has different libraries.  For a quick and dirty test
> of the debug agent though, I'll frequently just run it on the host in
> which case using the host's libraries is correct.

Same; I do almost all of my testing using gdbserver on the host. 
Because it has a different threads package than core GDB, I also
periodically recommend that others try this.  Having to set it myself
would be a real pain.

> As noted earlier in this thread (and by yourself on at least one
> occassion), one of the things which we sorely need is a mechanism to
> check to see if gdb has loaded the correct shared object.

Absolutely.  I'm thinking about this one...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Daniel Jacobowitz]

On Mon, Aug 12, 2002 at 12:19:52PM -0400, Andrew Cagney wrote:
> 
> >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?
> 
> Well, looking at some finally dead hacks, ....
> 
> int
> remote_Z_write_wp_packet_supported_p (void)
> {
>   struct remote_state *rs = get_remote_state ();
>   /* Don't even think about it if the remote target isn't selected.  */
>   /* FIXME: cagney/2002-05-19: This shouldn't be necessary - the
>      WATCHPOINT methods should be in the target vector.  Ulgh!  */
>   if (target_shortname == NULL
>       || strcmp (target_shortname, "remote") != 0)
>     return 0;
> 
> notice that the problem it was trying to avoid was with ``target sim''. 
>  So in the above the question is no longer local/remote but local VS 
> remote VS sim VS ....

Note that the above hack doesn't even work.  We're going to default to
extended-remote for gdbserver eventually.  Could do it with strstr, I
suppose...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Kevin Buettner]

On Aug 12, 12:19pm, Andrew Cagney wrote:

> > 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?
> 
> Well, looking at some finally dead hacks, ....
> 
> int
> remote_Z_write_wp_packet_supported_p (void)
> {
>    struct remote_state *rs = get_remote_state ();
>    /* Don't even think about it if the remote target isn't selected.  */
>    /* FIXME: cagney/2002-05-19: This shouldn't be necessary - the
>       WATCHPOINT methods should be in the target vector.  Ulgh!  */
>    if (target_shortname == NULL
>        || strcmp (target_shortname, "remote") != 0)
>      return 0;
> 
> notice that the problem it was trying to avoid was with ``target sim''. 
>   So in the above the question is no longer local/remote but local VS 
> remote VS sim VS ....

Actually, I think it's probably better to recast the question in terms
of native vs. non-native targets.  For native targets, I think it's
appropriate for solib_open() to examine the host environment
variables.  (Though there are still cases where even this is wrong.)
For non-native targets, I think the user should be required to have
settings for solib-absolute-prefix and solib-search-path.  (Though
as Daniel pointed out, there are cases when it would be okay to use
the host's environment variables.)

Kevin

GDB functionalities for debugging Elf core dump

[Lucy Zhang]

Hi,

I was wondering where I could find a list of functionalities that GDB has in
working with Elf core dumps. I've read the GDB manual on the website, but
I'm looking for a specific list of things I could use with the Elf core dump
I've created to test its correctness? It'd be great if people knew other
webpages that describe what GDB can do with a core dump or if people could
help list the different functionalities.

Thanks,
Lucy