This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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. :-)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]