mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-24 04:00:07 +08:00
a4a1c15754
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.
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.