This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: checked in: Re: RFC: solib.c:solib_map_sections so->so_name clobbering
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Luis Machado <lgustavo at codesourcery dot com>
- Cc: "'gdb-patches at sourceware dot org'" <gdb-patches at sourceware dot org>
- Date: Wed, 4 Dec 2013 20:59:40 +0400
- Subject: Re: checked in: Re: RFC: solib.c:solib_map_sections so->so_name clobbering
- Authentication-results: sourceware.org; auth=none
- References: <526B2936 dot 3080208 at codesourcery dot com> <526B2A53 dot 7080905 at codesourcery dot com> <20131026042902 dot GE4769 at adacore dot com> <526C7E65 dot 6050308 at codesourcery dot com> <20131028113939 dot GC3066 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