This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/16818] GDB crashes when using name for target remote hostname:port
- From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Tue, 03 May 2016 09:42:53 +0000
- Subject: [Bug gdb/16818] GDB crashes when using name for target remote hostname:port
- Auto-submitted: auto-generated
- References: <bug-16818-4717 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=16818
--- Comment #9 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Pedro Alves <palves@sourceware.org>:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a4a1c15754d144d14dc48cd8ff62601f977e908c
commit a4a1c15754d144d14dc48cd8ff62601f977e908c
Author: Pedro Alves <palves@redhat.com>
Date: Tue May 3 10:30:51 2016 +0100
Fix PR gdb/16818, workaround Python's forcing of -export-dynamic
GDB's use of --dynamic-list to only export the proc-service symbols is
broken due to Python's "python-config --ldflags" saying we should link
with -export-dynamic, causing us to export _all_ extern symbols
anyway. On Fedora 23:
$ python-config --ldflags
-lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic
$ python3.4-config --ldflags
-L/usr/lib64 -lpython3.4m -lpthread -ldl -lutil -lm -Xlinker
-export-dynamic
Having GDB export all its symbols leads to issues such as PR gdb/16818
(GDB crashes when using name for target remote hostname:port), where a
GDB symbol unintentionally preempts a symbol in one of the NSS modules
glibc loads into the process. NSS modules should not define symbols
outside the implementation namespace or the relevant standards, but,
alas, that's a longstanding and hard to fix issue. See libc-alpha
discussion at:
[symbol name space issues with NSS modules]
https://sourceware.org/ml/libc-alpha/2016-04/msg00130.html
Python should instead be either using GCC's symbol visibility feature
or -Wl,--dynamic-list as well, to only export Python API symbols, but,
it doesn't. There are bugs open upstream for that:
[Use -Wl,--dynamic-list=x.list, not -Xlinker -export-dynamic]
http://bugs.python.org/issue10112
[Use GCC visibility attrs in PyAPI_*]
http://bugs.python.org/issue11410
But that's taking a long while to resolve.
I thought of working around this Python issue by making GDB build with
-fvisibility=hidden, as Jan suggests in Python issue 10112, as then
Python's "-Xlinker -export-dynamic" has no effect. However, that
would need to be done in the whole source tree (bfd, libiberty, etc.),
and I think that would break GCC plugins, as I believe those have
access to all of GCCs symbols, by "design". So we'd need a new
configure switch, or have the libraries in the tree detect which of
GCC or GDB is being built, but that doesn't work, because the answer
can be "both" with combined builds...
So this patch instead works around Python's bug, by simply sed'ing
away "-Xlinker -export-dynamic" from the result of python-config.py
--ldflags, making -Wl,--dynamic-list work again as it used to. It's
ugly, but so is the bug...
Note that if -Wl,--dynamic-list doesn't work, we always link with
-rdynamic, so static Python should still work.
Tested on F23 with --python=python (Python 2.7) and
--python=python3.4.
gdb/ChangeLog:y
2016-05-03 Pedro Alves <palves@redhat.com>
* configure.ac (PYTHON_LIBS): Sed away "-Xlinker -export-dynamic".
* configure: Regenerate.
--
You are receiving this mail because:
You are on the CC list for the bug.