This is the mail archive of the gdb-prs@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]

[Bug gdb/16818] GDB crashes when using name for target remote hostname:port


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.

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