Re: symfile.c:symfile_bfd_open()

[Andrew Cagney <ac131313 at cygnus dot com>]

Todd Whitesel wrote:
> 
> > > 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?
> 
> It's not a user-settable option. (I never said these patches were clean;
> in fact I was hoping to find a good way to clean them up, but it looks
> like I've merely uncovered a more general issue that multi-arch is going
> to raise as work continues on it.)

I don't think this is a multi-arch problem but rather a target problem. 
As JimB mentioned, the ``PATH'' might be different for a local or remote
target (yet the architecture is the same).

While on the topic.  Don't assume (post 5.0) that ``(gdb) target ...''
will directly call target->open().  One of the road blocks to
progressing async, multi-arch and a few other things is that unfortunate
bit of design.

> > > 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.
> 
> Kinda figured as much. This is something that multi-arch GDB does in
> fact lose relative to a single-arch GDB, then.
> 
> I can think of at least 3 strategies for dealing with this, but the
> bottom line is that GDB lets people pick files before requiring that
> they pick a target. Perhaps this itself is what's wrong.
> 
> Anyway, the basic ambiguity right now is that you will probably want
> a different PATH searched depending on native/cross, but GDB doesn't
> know that answer yet.

If you specify ``file ...'' then, for some targets, this forces ``target
exec'':

	(gdb) target sim
	Connected to the simulator.
	(gdb) file ~/tmp/hello.d10v
	A program is being debugged already.  Kill it? (y or n) y

	Reading symbols from ~/tmp/hello.d10v...done.
	(gdb) load
	You can't do that when your target is `exec'

The entire thing needs a rethink.

	Andrew