This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: symfile.c:symfile_bfd_open()
- To: Todd Whitesel <toddpw at windriver dot com>
- Subject: Re: symfile.c:symfile_bfd_open()
- From: Jim Blandy <jimb at zwingli dot cygnus dot com>
- Date: 24 Mar 2000 19:06:31 -0500
- Cc: gdb at sourceware dot cygnus dot com (GDB Developers)
- References: <200003241351.FAA06850@alabama.wrs.com>
> While merging up to 4.18 (as a stepping stone to devo), I noticed
> something that we're doing locally here which seems generally useful
> for cross developing folks.
>
> symfile.c:symfile_bfd_open() opens objects/executables using BFD.
>
> It tells openp() to search the $PATH, which is obviously handy for
> native, but seems to make no sense whatsoever for cross development.
Yep.
> Our local patch is to add a second argument to symfile_bfd_open,
> "use_source_path", which ends up being set to 1 nearly all of the
> time, since with our targets we are always cross developing. In
> that case, we have openp() search source_path instead of getenv("PATH").
How do you decide what to pass for the use_source_path argument? Is
it a user-settable option?
> Does the multi-arch stuff provide a clean test for native vs. cross?
> That'd be a better decision-maker than the "use_source_path" argument.
I don't think you can tell at all. What if I'm debugging an i386
embedded system on Linux? Then, whether I'm native or remote is a
matter of which target I select.