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

[Joel Brobecker <brobecker at adacore dot com>]

I just realize I dropped the ball on this, apologies! And it affects
the 7.7 release as well. So I first started by adding this AI,
with my name attached to it, to the gdb-7.7 release wiki page.

I plan on going ahead with the proposal below as soon as I have
a moment. If there are other suggestion, please do not hesitate.

On Mon, Oct 28, 2013 at 03:39:39PM +0400, Joel Brobecker wrote:
> > >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?

-- 
Joel