Re: checked in: Re: RFC: solib.c:solib_map_sections so->so_name clobbering

[Joel Brobecker <brobecker@adacore.com>]

> >So it looks like we've lost information about the shared library's path
> >on the host, which may not be a big deal for CLI GDB, but may confuse
> >consumers of MI output.

Agreed.

Can you also check the output of "info shared" in GDB/CLI mode?
I suspect that you might have a change in behavior there as well.
Whether this change is actually a Good Thing or not, is unclear,
as the manual does not say whether the names are expected to be
host-side paths, or target-side paths.

> >I gave this a quick thought, but reverting the change seemed like the
> >most obvious solution.
> >
> >But since this change affects darwin, maybe Joel has a different idea?

This would also affect AIX.

It might probably need more thought, but at first sight, I am wondering
whether the real issue is that the solib backend created an entry
where "so_name" does not match the field description:

    /* Shared object file name, expanded to something GDB can open.  */

My suspicion is that the bfd_open callback takes care of the path
translation, so the backend was allowing itself to defer it. I am
not sure how difficult it would be to move that part to each backend.

Reverting the patch would be a real issue, because it would mean
that any given solib backend cannot set the so_name, and commands
such as "info shared" would print a bogus shared library name.
Nevertheless, if we did revert it, I think we can work around
the issue by using the same trick as the one we used for the 7.6
branch IIRC.

-- 
Joel