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

[Joel Brobecker <brobecker@adacore.com>]

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

I had the weekend to think about it some more. To me, the most
important aspect is that the output in GDB/MI is now incorrect,
not just confusing. So I think something should be done about it,
and sooner rather than later.

At the moment, the approach I dislike the least is to revert
my patch, and let the couple of solib backends (darwin, AIX)
fix up the BFD filename, the same way we did on the gdb-7.6
branch:
http://www.sourceware.org/ml/gdb-patches/2013-03/msg01084.html

This fixup is what we used to do in the past, except that we were
leaking memory. It's possible to do the same without the memory leak,
thanks to a suggestion from Tom.  It sounds contradictory to be
suggesting this, since I think this is clearly a step in the wrong
direction (making the semantics of that field a little iffy, since
time-sensitive), but seems like an acceptable compromise between amount
of work vs severity of the problem.

The alternative would be, I think, to make sure that the various
solib backends set the so_name properly. I'm not sure whether
that's actually possible. I would need to study the framework
a little longer, but lack the time at the moment.

Other thoughts/suggestions?

Thanks,
-- 
Joel