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: Sat, 26 Oct 2013 08:29:02 +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>
> >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.
> >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. */
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.
--
Joel