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: Mon, 28 Oct 2013 15:39:39 +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>
> >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