Re: symfile.c:symfile_bfd_open()

[Todd Whitesel <toddpw at windriver dot com>]

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

Since the main caller of symfile_bfd_open is symbol_file_add, we end up
adding an argument to him too, and that is what actually gets set by the
existing patches. The "decision" about what value to pass (if you can call
it that) is that in all the important cases we pass 1. All the lesser-used
(or never used!) cases pass 0.

It is my belief that all the 0 cases are incorrect yet harmless, but since
they almost never get used, no one was ever motivated to change them. I've
left them alone so far, because I had plenty else to do and they didn't
conflict with anything I was merging -- until 4.18 came along, that is.

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

Maybe the better solution is to have a three-state user settable option,
where the default is to search both PATH's, binary first and source second.

I expect in the future there will be more cases like this, where code that
always used to "just work" in the single GDB case finds itself lacking
information in the multi-arch arena because the target hasn't been chosen
yet, and no object files have been loaded. (This case is a little ironic,
in that it controls how we FIND those object files in the first place!)

-- 
Todd Whitesel
toddpw @ windriver.com