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: Luis Machado <lgustavo at codesourcery dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: "'gdb-patches at sourceware dot org'" <gdb-patches at sourceware dot org>
- Date: Sun, 27 Oct 2013 00:45:57 -0200
- 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>
- Reply-to: lgustavo at codesourcery dot com
On 10/26/2013 02:29 AM, Joel Brobecker wrote:
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.
It does affect "info shared". It displays the target path instead of the
host path now.
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. */
Yeah, by so_name i'd expect a canonical library name with no additional
bits of path.
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. :-)