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

[Luis Machado <lgustavo@codesourcery.com>]

On 10/26/2013 02:29 AM, Joel Brobecker wrote:
>>> 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.
>

It does affect "info shared". It displays the target path instead of the 
host path now.

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

Yeah, by so_name i'd expect a canonical library name with no additional 
bits of path.

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

I wouldn't say this is critical, just a slight change from an 
undocumented direction we've been following. :-)