mirror of
https://github.com/bminor/binutils-gdb.git
synced 2025-12-26 09:08:59 +00:00
2c473def12
Without any explicit dependencies specified, the observers attached to the 'gdb::observers::new_objfile' observable are always notified in the order in which they have been attached. The new_objfile observer callback to auto-load scripts is attached in '_initialize_auto_load'. The new_objfile observer callback that propagates the new_objfile event to the Python side is attached in 'gdbpy_initialize_inferior', which is called via '_initialize_python'. With '_initialize_python' happening before '_initialize_auto_load', the consequence was that the new_objfile event was emitted on the Python side before autoloaded scripts had been executed when a new objfile was loaded. As a result, trying to access the objfile's pretty printers (defined in the autoloaded script) from a handler for the Python-side 'new_objfile' event would fail. Those would only be initialized later on (when the 'auto_load_new_objfile' callback was called). To make sure that the objfile passed to the Python event handler is properly initialized (including its 'pretty_printers' member), make sure that the 'auto_load_new_objfile' observer is notified before the 'python_new_objfile' one that propagates the event to the Python side. To do this, make use of the mechanism to explicitly specify dependencies between observers (introduced in a preparatory commit). Add a corresponding testcase that involves a test library with an autoloaded Python script and a handler for the Python 'new_objfile' event. (The real world use case where I came across this issue was in an attempt to extend handling for GDB pretty printers for dynamically loaded objfiles in the Qt Creator IDE, s. [1] and [2] for more background.) [1] https://bugreports.qt.io/browse/QTCREATORBUG-25339 [2] https://codereview.qt-project.org/c/qt-creator/qt-creator/+/333857/1 Tested on x86_64-linux (Debian testing). gdb/ChangeLog: * gdb/auto-load.c (_initialize_auto_load): 'Specify token when attaching the 'auto_load_new_objfile' observer, so other observers can specify it as a dependency. * gdb/auto-load.h (struct token): Declare 'auto_load_new_objfile_observer_token' as token to be used for the 'auto_load_new_objfile' observer. * gdb/python/py-inferior.c (gdbpy_initialize_inferior): Make 'python_new_objfile' observer depend on 'auto_load_new_objfile' observer, so it gets notified after the latter. gdb/testsuite/ChangeLog: * gdb.python/libpy-autoloaded-pretty-printers-in-newobjfile-event.so-gdb.py: New test. * gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event-lib.cc: New test. * gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event-lib.h: New test. * gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event-main.cc: New test. * gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event.exp: New test. * gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event.py: New test. Change-Id: I8275b3f4c3bec32e56dd7892f9a59d89544edf89
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.