aboutsummaryrefslogtreecommitdiff
path: root/gdb/python
AgeCommit message (Collapse)AuthorFilesLines
9 hoursRewrite output redirection and loggingTom Tromey1-8/+2
This patch changes how gdb output redirection is done. Currently, output is done via the UI. gdb_stdout, for example, is a define the expands to an lvalue referencing a field in the current UI. When redirecting, this field may temporarily be reset; and when logging is enabled or disabled, this is also done. This has lead to bugs where the combination of redirection and logging results in use-after-free. Crashes are readily observable; see the new test cases. This patch upends this. Now, gdb_stdout is simply an rvalue, and refers to the current interpreter. The interpreter provides ui_files that do whatever rewriting is needed (mostly for MI); then output is forward to the current UI via an indirection (see the new ui::passthrough_file). The ui provides paging, logging, timestamps, and the final stream that writes to an actual file descriptor. Redirection is handled at the ui layer. Rather than changing the output pipeline, new ui_files are simply swapped in by rewriting pointers, hopefully with a scoped_restore. Redirecting at the ui layer means that interpreter rewriting is still applied when capturing output. This fixes one of the reported bugs. Not changing the pipeline means that the problems with the combination of redirect and logging simply vanish. Logging just changes a flag and doesn't involve object destruction. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17697 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28620 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28798 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28948 Approved-By: Andrew Burgess <aburgess@redhat.com>
9 hoursRemove m_applied_style from ui_fileTom Tromey1-2/+3
While working on this series, I found a number of odd styling issues recurred. For instance, the issue where the pager would lose track and style subsequent output incorrectly reappeared. It turned out that different ui_file objects in the output pipeline would get confused about their current style. And, looking deeper at this, I realized that mainly it is the pager that really needs to track the current style at all. All the other file implementations can be purely reactive (except the buffered stream code, as Andrew pointed out). This patch moves m_applied_style from ui_file and into pager_file. This necessitated making ui_file::vprintf virtual, so that the base class could pass in the "plain" style as the starting point, whereas the pager could use the applied style. (I did not investigate whether this was truly necessary, and I somewhat suspect it might not be.) This straightforward approach caused some regressions, mostly involving extra ANSI escapes being emitted. I fixed most of these by arranging for ui_out::call_do_message to track styles a little more thoroughly. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
11 days[gdb/python] Fix whitespace in py-ref.hTom de Vries1-1/+1
Fix a whitespace problem pre-commit complains about: ... check-whitespace........................................................Failed - hook id: check-whitespace - exit code: 2 gdb/python/py-ref.h:58: indent with spaces. + "The __dict__ for this object.", nullptr }, ...
11 daysgdb: make remaining Python extension objects inherit from PyObjectMatthieu Longo16-62/+37
Previous patches made some Python extension objects ipublicly inherit directly or indirectly from PyObject. In the interest of consistency, this patch makes all remaining Python extension objects still not inheriting from PyObject do so. Approved-By: Tom Tromey <tom@tromey.com>
11 daysgdb: cast all Python extension objects passed to gdbpy_ref_policy to PyObject*Matthieu Longo14-49/+25
When enabling the Python limited API, pointers to Python C extension objects can no longer be implicitly converted to 'PyObject *' by the compiler. gdbpy_ref_policy is a templated class that provides a generic interface for incrementing and decrementing the reference counter on the given object. It is used as a specialisation of the policy parameter in gdb::ref_ptr, together with PyObject as the parameter type. As a result, gdbpy_ref_policy always expects an argument derived from PyObject. This patch fixes the resulting compilation issue by adding an explicit static_cast to 'PyObject *' before passing the value to Py_INCREF and Py_DECREF. As a side effect, these casts enforce, at compile time, that the template type passed to gdbpy_ref_policy is a subclass of PyObject. To provide a clearer diagnostic when an incorrect type is used, a static_assert is added to gdbpy_ref_policy, avoiding obscure errors originating from the static_cast. Finally, all C Python extension types passed to gdbpy_ref_policy are updated to inherit from PyObject. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23830 Approved-By: Tom Tromey <tom@tromey.com>
11 daysgdb: new setters and getters for __dict__, and attributesMatthieu Longo11-108/+184
GDB is currently using the Python unlimited API. Migrating the codebase to the Python limited API would have for benefit to make a GDB build artifacts compatible with older and newer versions of Python that they were built with. This patch prepares the ground for migrating the existing C extension types from static types to heap-allocated ones, by removing the dependency on tp_dictoffset, which is unavailable when using the limited API. One of the most common incompatibilities in the current static type declarations is the tp_dictoffset slot, which specifies the dictionary offset within the instance structure. Historically, the unlimited API has provided two approaches to supply a dictionary for __dict__: * A managed dictionary. Setting Py_TPFLAGS_MANAGED_DICT in tp_flags indicates that the instances of the type have a __dict__ attribute, and that the dictionary is managed by Python. According to the Python documentation, this is the recommended approach. However, this flag was introduced in 3.12, together with PyObject_VisitManagedDict() and PyObject_ClearManagedDict(), neither of which is part of the limited API (at least for now). As a result, this recommended approach is not viable in the context of the limited API. * An instance dictionary, for which the offset in the instance is provided via tp_dictoffset. According to the Python documentation, this "tp slot" is on the deprecation path, and Py_TPFLAGS_MANAGED_DICT should be used instead. Given the age of the GDB codebase and the requirement to support older Python versions (>= 3.4), no need to argue that today, the implementation of __dict__ relies on tp_dictoffset. However, in the context of the limited API, PyType_Slot does not provide a Py_tp_dictoffset member, so another approach is needed to provide __dict__ to instances of C extension types. Given the constraints of the limited API, the proposed solution consists in providing a dictionary through a common base class, gdbpy__dict__wrapper. This helper class owns a dictionary member corresponding to __dict__, and any C extension type requiring a __dict__ must inherit from it. Since extension object must also be convertible to PyObject, this wrapper class publicly inherits from PyObject as well. Access to the dictionary is provided via a custom getter defined in a PyGetSetDef, similarily to what was previously done with gdb_py_generic_dict(). Because __dict__ participates in attribute look-up, and since this dictionary is neither managed by Python nor exposed via tp_dictoffset, custom implementations of tp_getattro and tp_setattro are required to correctly redirect attribute look-ups to the dictionary. These custom implementations — equivalent to PyObject_GenericGetAttr() and PyObject_GenericSetAttr() — must be installed via tp_getattro / tp_setattro for static types, or Py_tp_getattro / Py_tp_setattro for heap-allocated types. - gdbpy__dict__wrapper: a base class for C extension objects that own a __dict__. - gdb_py_generic_dict_getter: a __dict__ getter for extension types derived from gdbpy__dict__wrapper. - gdb_py_generic_getattro: equivalent of PyObject_GenericGetAttr, but fixes the look-up of __dict__. - gdb_py_generic_setattro: equivalent of PyObject_GenericSetAttr, but fixes the look-up of __dict__. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23830 Approved-By: Tom Tromey <tom@tromey.com>
11 daysgdbpy_registry: cast C extension type object to PyObject * before Py_XINCREFMatthieu Longo4-9/+11
When enabling the Python limited API, pointers to Python C extension objects can no longer be implicitly converted to 'PyObject *' by the compiler. The lookup() method of gbdpy_registry returns a new reference to the type object of the looked-up entry. It does so by calling Py_XINCREF() to increment the reference counter of the returned type object. The template parameter obj_type corresponds to the type of C extension object type. With the Python limited API enabled, obj_type can no longer be implicitly converted to 'PyObject *' when passed to Py_XINCREF(). This patch fixes the resulting compilation issue by adding an explicit static_cast to 'PyObject *' before passing the value to Py_XINCREF(). As a side effect, this cast enforces, at compile time, that the template type 'Storage::obj_type' passed to gdbpy_registry is a subclass of PyObject. To provide a clearer diagnostic when an incorrect type is used, a static_assert is added to gdbpy_registry, avoiding obscure errors originating from the static_cast. Finally, the relevant C extension types passed to gdbpy_registry are updated to inherit publicly from PyObject. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23830 Approved-By: Tom Tromey <tom@tromey.com>
13 daysPython limited API: migrate PyImport_ExtendInittabMatthieu Longo1-8/+2
This patch replaces PyImport_ExtendInittab () with its limited C API equivalent, PyImport_AppendInittab (), a convenience wrapper around PyImport_ExtendInittab (). Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23830 Approved-By: Tom Tromey <tom@tromey.com>
13 daysPython limited API: migrate Py_CompileStringExFlags and PyRun_SimpleStringMatthieu Longo3-11/+14
This patch replaces Py_CompileStringExFlags () with its limited C API equivalent, Py_CompileString (). The eval_python_command () helper is now exposed through the private GDB Python API as a utility function. PyRun_SimpleString () is replaced with eval_python_command () to avoid code duplication. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23830 Approved-By: Tom Tromey <tom@tromey.com>
14 daysgdb/python: use gdbpy_is_value_object in more placesoltolm1-2/+2
Make more use of gdbpy_is_value_object in python/py-value.c Approved-By: Andrew Burgess <aburgess@redhat.com>
2026-01-23Update black to 26.1.0Tom Tromey8-18/+16
"pre-commit autoupdate" suggests a new version of black. This version seems to want to change how destructuring assignments are formatted. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2026-01-16Use make_unique_xstrdup in more placesTom Tromey4-4/+7
This replaces a number of uses of 'ptr.reset (xstrdup ())' with 'ptr = make_unique_xstrdup ()'. The main motivation for this is that, IMO, it's better to avoid the reset method when possible. Approved-By: Andrew Burgess <aburgess@redhat.com>
2026-01-14py-gdb-readline: replace deprecated interfaces in GdbRemoveReadlineFinderMatthieu Longo1-9/+18
A previous patch [1] enabled readline in Python in a GDB-specific way and blocked the standard Python readline module to prevent conflicts with GDB by adding a custom importer raising an exception for the readline module. This custom importer was written back in 2012 for old Python versions, and does not seem to work anymore with Python 3.x. find_module() and load_module() have been deprecated since Python 3.4, and the first one has been removed since 3.12, and the second will be removed in 3.15. The GDB testsuite does not cover this use case, and the removal of find_module() was not detected by the testsuite. This issue is tracked in bug 32473. importlib.abc.MetaPathFinder: find_module(fullname, path) Deprecated since version 3.4: Use find_spec() instead. Changed in version 3.10: Use of find_module() by the import system now raises ImportWarning. Changed in version 3.12: find_module() has been removed. Use find_spec() instead. find_spec(fullname, path, target=None) New in version 3.4, as a replacement for find_module. importlib.abc.Loader: load_module(fullname): Deprecated since version 3.4, will be removed in version 3.15 The recommended API for loading a module is exec_module() (and create_module()). This patch uses Patryk Sondej's approach detailed in bug 32473, but with a slight variation regarding the finder insertion in sys.meta_path. It also adds a new test to prevent future regression. [1]: 037bbc8eeaf8e6f3a5e185e78268aa71a1159ae7 Approved-By: Tom Tromey <tom@tromey.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32473
2026-01-09Show constants in DAP scopes outputTom Tromey1-2/+3
This changes the DAP code so that constants will now be returned by a DAP scopes request. This is perhaps slightly strange with Ada enumerators, but on the other hand this is consistent with what the CLI does. Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2026-01-09Allow DAP client to set Ada source charset at launchTom Tromey1-0/+6
A co-worker reported that certain symbols weren't appearing in the DAP 'scopes' response. In particular, symbols with non-ASCII names didn't appear; though further research showed that this was in fact a result of the variable in question actually being a constant. Unfortunately Ada still requires the user to set the Ada source character set in order to properly display symbol names. For DAP, it seemed to make sense to allow this as a launch parameter. This patch implements this. Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2026-01-09Explicitly use print_name in DAPTom Tromey3-4/+4
This changes some DAP code to explicitly use a symbol's print name. Some places were using '.name'; and while 'str' does use the print name, it seems better to be both consistent and explicit.
2026-01-06gdb: remove make_cv_type typeptr parameterSimon Marchi2-7/+6
It is always passed nullptr. Change-Id: Iecc170545c0504af35d83bcb06e07d29994d18e1 Approved-By: Tom Tromey <tom@tromey.com>
2026-01-06Small cleanup to interpreter initializationTom Tromey1-2/+2
interp::inited is currently public, because interp_set does the task of making sure the interpreter is only initialized a single time. However, the interpreter can do this job itself, and this member can be private.
2026-01-05Update copyright dates to include 2026Tom Tromey120-120/+120
This updates the copyright headers to include 2026. I did this by running gdb/copyright.py and then manually modifying a few files as noted by the script.
2026-01-05Add Ada unhandled exception filter to DAPTom Tromey1-1/+8
This adds a way for DAP clients to catch unhandled Ada exceptions, similar to the "catch exception unhandled" CLI command. Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2026-01-05Change handling of over-long DAP variables requestsTom Tromey1-3/+5
In PR dap/33228, we changed gdb to gracefully report an error if a DAP 'variables' request asked for more variables than had been reported. This behavior was clarified in the spec, see https://github.com/microsoft/debug-adapter-protocol/issues/571 This patch changes gdb to conform to the specified approach, namely truncating the list rather than erroring. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33228 Approved-By: Andrew Burgess <aburgess@redhat.com>
2026-01-05Fix DAP 'disconnect' implementationTom Tromey1-3/+19
gdb's implementation of the DAP 'disconnect' request was incorrect in a few ways. First, the 'terminateDebuggee' field is optional, and has a special meaning when not supplied: it should do whatever the default is. Second, if the inferior was attached, it should detach rather than terminate by default. Finally, if the inferior was not started at all, it seems reasonable for this request to simply succeed silently -- currently it returns "success: false" with the reason being that the inferior isn't running. Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-12-22Use string_view in user_reg_map_name_to_regnumTom Tromey1-4/+2
This changes user_reg_map_name_to_regnum to use std::string_view. This pointed out some dead code in that function: the "len < 0" test in the loop can never be true, because earlier code changes 'len' in this case. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-12-18Don't use "module" nameTom Tromey7-21/+21
In C++20, "module" is an "identifier with special meaning". While it can be used as a variable name, it highlights as a keyword in Emacs, and I think it's nicer to just avoid it. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32660
2025-12-15DAP: accept requests with '"arguments": null'Ronan Desplanques1-1/+9
Some Debug Adapter Protocol clients like Helix set the optional "arguments" field of the ConfigurationDone request to null, which is a bit odd but seems to be allowed by the protocol specification. Before this patch, Python exceptions would be raised on such requests. This patch makes it so these requests are treated as if the "arguments" field was absent.
2025-11-26gdb: fix some whitespace issuesSimon Marchi2-5/+5
Replace 8 spaces with a tab. Change-Id: Ie8f942ce4b4ba4a83c2ee83cb904153b2e58cf8c
2025-11-14Reject negative children in DAPTom Tromey1-1/+6
This changes DAP to ignore the case where a pretty-printer returns a negative number from the num_children method. It didn't seem worth writing a test case for this. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33594 Reviewed-By: Ciaran Woodward <ciaranwoodward@xmos.com>
2025-11-14Have DAP handle multiple breakpoints at same locationTom Tromey1-9/+11
A user pointed out that if multiple breakpoints are set at the same spot, in DAP mode, then changing the breakpoints won't reset all of them. The problem here is that the breakpoint map only stores a single breakpoint, so if two breakpoints have the same key, only one will be stored. Then, when breakpoints are changed, the "missing" breakpoint will not be deleted. The fix is to change the map to store a list of breakpoints. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33467 Reviewed-By: Ciaran Woodward <ciaranwoodward@xmos.com>
2025-11-14Rename variable in DAP breakpoint.pyTom Tromey1-5/+5
This renames the variable 'breakpoint_map' in DAP's breakpoint.py, adding an underscore to make it clear that it is private to the module. Reviewed-By: Ciaran Woodward <ciaranwoodward@xmos.com>
2025-11-11Allow Python to create const+volatile typesTom Tromey1-4/+4
A user pointed out that the Python API can't create a type that is both const and volatile. The bug is that the calls to make_cv_type did not preserve the "other" flag. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33585 Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
2025-11-06gdb/python: fix gdb.Block repr outputAndrew Burgess1-1/+7
I noticed that when printing a gdb.Block object in Python, I would occasionally get corrupted, nonsensical output, like this: <gdb.Block <anonymous> {intintyinty_1inty_3inty_5... (-5 more symbols)}> The symbol list is missing commas, it should be: int, inty, inty_1, inty_3, inty_5, ... And the '-5 more symbols' is clearly not right. The problem is in python/py-block.c, we use this line to calculate the number of symbols in a block: const int len = mdict_size (block->multidict ()); Then we loop over the symbols in the block like this: for (struct symbol *symbol : block_iterator_range (block)) ... The problem here is that 'block_iterator_range (block)' can loop over more symbols than just those within 'block'. For global and static blocks, block_iterator_range() takes into account included CUs; and so can step through multiple global or static blocks. See block_iterator_step and find_iterator_compunit_symtab in block.c for more details. In contrast, 'mdict_size (block->multidict ())' only counts the symbols contained within 'block' itself. I could fix this by either fixing LEN, or by only iterating over the symbols within 'block'. I assume that printing a gdb.Block object is used mostly for debug purposes; the output isn't really user friendly, so I cannot imagine a user script that is relying on printing a gdb.Block as a way to inform the user about blocks in their program. As such, I think it makes more sense if the symbols listed are restricted to those strictly held within the block. And so, instead of block_iterator_range, I've switched to iterating over the multidict symbols. Now the calculated LEN will match the number of symbols being printed, which fixes the output seen above. However, as we're now only printing symbols that are within the block being examined, the output above becomes: <gdb.Block <anonymous> {}> All the symbols that GDB previously tried to print, are coming from an included CU. For testing, I've made use of an existing DWARF test that tests DW_AT_import. In the wild I saw this in an inferior that used multiple shared libraries that has their debug information stored in a separate debug file, and then parts of that debug information was combined into a third separate file using the DWZ tool. I made a few attempts to craft a simpler reproducer, but failed. In the end it was easier to just use a DWARF assembler test to reproduce the issue. I have added some more typedef symbols into the DWARF test, I don't believe that this will impact the existing test, but makes the corrupted output more obvious. Approved-By: Tom Tromey <tom@tromey.com>
2025-11-05gdb: add "essential" command classGuinevere Larsen1-1/+3
Currently, there is no way for a new user to have an idea of common useful commands and behaviors from the GDB interface itself, without checking the example session in the documentation. This command class aims to close that gap by providing a set of quickstart commands that allows for any simple debug session to happen without anything too egregious missing. The set of commands was chosen somewhat arbitrarily, based on what I used or missed the most. The one overarching important thing, however, is that the list is kept short, so as to not overwhelm new users. This is confirmed by the newly introduced selftest, essential_command_count, which ensures there are 20 or fewer essential commands. Here's the reasoning for some of the choices: * The command "start" was picked over "run" because combining it with "continue" achieves the same effect, and I prefer it over needing to set a breakpoint on main to stop at the start of the inferior. * The command "ptype" is chosen because I believe it is important to provide a way for the user to check a variable's type from inside GDB, and ptype is a more complete command than the alternative, "whatis". Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
2025-11-02gdb: add a constructor for symtabAndrew Burgess1-2/+2
Convert symtab to use obstack_new, and have a real constructor. The filename, filename_for_id and m_compunit, members should really not change once the symtab has been created, so make these members private (m_compunit was already private) and set them just once from the constructor. The set_compunit function has been deleted, and new getter functions for filename and filename_for_id have been added. The language is also set at construction time, but can be updated later, so set the language in the constructor, but retain symtab::set_language for when the language needs to be updated. Prior to this patch the symtab was allocated with OBSTACK_ZALLOC which would zero out the symtab object. With the call to objstack_new fields in the symtab would no longer be initialised, so I've added default member initialisation for everything not set in the constructor. The interesting changes are in symtab.h, and symfile.c. Everything else is just updating to handle symfile::filename and symfile::filename_for_id becoming methods. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-10-24gdb: add gdb_rl_tilde_expand utilSimon Marchi1-1/+0
Add gdb_rl_tilde_expand, a wrapper around readline's tilde_expand that returns a gdb::unique_xmalloc_ptr<char>. Change all callers of tilde_expand to use gdb_rl_tilde_expand (even the couple of spots that release it immediatly, for consistency). This simplifies a few callers. The name gdb_tilde_expand is already taken by a home-made implementation in gdbsupport/gdb_tilde_expand.{h.cc}. I wonder if we could just use that one instead of readline's tilde_expand, but that's an orthogonal question. I don't know how they differ, and I don't want to introduce behavior changes in this patch. Change-Id: I6d34eef19f86473226df4ae56d07dc01912e3131 Approved-By: Tom Tromey <tom@tromey.com>
2025-10-23gdb: change find_pcs_for_symtab_line() to return entries instead of PCsJan Vrany1-9/+14
This commit changes find_pcs_for_symtab_line() to return complete linetable entries instead of just PCs. This is a preparation for adding more attributes to gdb.LinetableEntry objects. I also renamed the function to find_linetable_entries_for_symtab_line() to better reflect what it does. Approved-By: Tom Tromey <tom@tromey.com>
2025-10-23Remove Python API checker definesTom Tromey38-198/+117
The GCC plugin that implements the Python API checker does not appear to really be maintained. And, as far as I know, it never really worked for C++ code anyway. Considering those factors, and that no one has tried to run it in years, I think it's time to remove the macros from the gdb source. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-10-23Remove Py_TPFLAGS_CHECKTYPESTom Tromey2-4/+1
According to 'git annotate', the Py_TPFLAGS_CHECKTYPES was added to python-internal.h way back when gdb was first ported to Python 3. It was a compatibility fix for Python 2. This is not needed any more, because Python 2 is no longer supported. This patch removes the vestiges. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-10-20gdb, gdbserver, gdbsupport: trim trailing whitespacesSimon Marchi4-15/+15
I noticed my IDE (VSCode) starting to automatically trim trailing whitespaces on save, despite the setting for it being disabled. I realized that this is because the .editorconfig file now has trim_trailing_whitespace = true for many file types. If we have this EditorConfig setting forcing editors to trim trailing whitespaces, I think it would make sense to clean up trailing whitespaces from our files. Otherwise, people will always get spurious whitespace changes when editing these files. I did a mass cleanup using this command: $ find gdb gdbserver gdbsupport -type f \( \ -name "*.c" -o \ -name "*.h" -o \ -name "*.cc" -o \ -name "*.texi" -o \ -name "*.exp" -o \ -name "*.tcl" -o \ -name "*.py" -o \ -name "*.s" -o \ -name "*.S" -o \ -name "*.asm" -o \ -name "*.awk" -o \ -name "*.ac" -o \ -name "Makefile*" -o \ -name "*.sh" -o \ -name "*.adb" -o \ -name "*.ads" -o \ -name "*.d" -o \ -name "*.go" -o \ -name "*.F90" -o \ -name "*.f90" \ \) -exec sed -ri 's/[ \t]+$//' {} + I then did an autotools regen, because we don't actually want to change the Makefile and Makefile.in files that are generated. Change-Id: I6f91b83e3b8c4dc7d5d51a2ebf60706120efe691
2025-10-20gdb: rename find_pc_line -> find_sal_for_pcSimon Marchi2-2/+2
Change-Id: I293b655e8753fc650f3ec10bb4e34a9632d8e377 Approved-by: Kevin Buettner <kevinb@redhat.com>
2025-10-20gdb: rename find_pc_compunit_symtab -> find_compunit_symtab_for_pcSimon Marchi1-1/+1
Change-Id: I6eef5db4ae55f3eb0415768207ae3c26b305f773 Approved-by: Kevin Buettner <kevinb@redhat.com>
2025-10-20gdb: rename find_pc_function -> find_symbol_for_pcSimon Marchi1-1/+1
Change-Id: I2069be1a6d7c3250cf330574c941bf851c89bab4 Approved-by: Kevin Buettner <kevinb@redhat.com>
2025-10-17[gdb/python] Use PyConfig for python 3.9Tom de Vries1-5/+15
On ppc64le-linux (AlmaLinux 9.6) with python 3.9 and test-case gdb.python/py-failed-init.exp I run into: ... builtin_spawn $gdb -nw -nx -q -iex set height 0 -iex set width 0 \ -data-directory $build/gdb/data-directory -iex set interactive-mode on^M Python path configuration:^M PYTHONHOME = 'foo'^M PYTHONPATH = (not set)^M program name = '/usr/bin/python'^M isolated = 0^M environment = 1^M user site = 1^M import site = 1^M sys._base_executable = '/usr/bin/python'^M sys.base_prefix = 'foo'^M sys.base_exec_prefix = 'foo'^M sys.platlibdir = 'lib64'^M sys.executable = '/usr/bin/python'^M sys.prefix = 'foo'^M sys.exec_prefix = 'foo'^M sys.path = [^M 'foo/lib64/python39.zip',^M 'foo/lib64/python3.9',^M 'foo/lib64/python3.9/lib-dynload',^M ]^M Fatal Python error: init_fs_encoding: failed to get the Python codec of the \ filesystem encoding^M Python runtime state: core initialized^M ModuleNotFoundError: No module named 'encodings'^M ^M Current thread 0x00007fffabe18480 (most recent call first):^M <no Python frame>^M ERROR: (eof) GDB never initialized. Couldn't send python print (1) to GDB. UNRESOLVED: gdb.python/py-failed-init.exp: gdb-command<python print (1)> Couldn't send quit to GDB. UNRESOLVED: gdb.python/py-failed-init.exp: quit ... The test-case expects gdb to present a prompt, but instead gdb calls exit with this back trace: ... (gdb) bt #0 0x00007ffff6e4bfbc in exit () from /lib64/glibc-hwcaps/power10/libc.so.6 #1 0x00007ffff7873fc4 in fatal_error.lto_priv () from /lib64/libpython3.9.so.1.0 #2 0x00007ffff78aae60 in Py_ExitStatusException () from /lib64/libpython3.9.so.1.0 #3 0x00007ffff78c0e58 in Py_InitializeEx () from /lib64/libpython3.9.so.1.0 #4 0x0000000010b6cab4 in py_initialize_catch_abort () at gdb/python/python.c:2456 #5 0x0000000010b6cfac in py_initialize () at gdb/python/python.c:2540 #6 0x0000000010b6d104 in do_start_initialization () at gdb/python/python.c:2595 #7 0x0000000010b6eaac in gdbpy_initialize (extlang=0x11b7baf0 <extension_language_python>) at gdb/python/python.c:2968 #8 0x000000001069d508 in ext_lang_initialization () at gdb/extension.c:319 #9 0x00000000108f9280 in captured_main_1 (context=0x7fffffffe870) at gdb/main.c:1100 #10 0x00000000108fa3cc in captured_main (context=0x7fffffffe870) at gdb/main.c:1372 #11 0x00000000108fa4d8 in gdb_main (args=0x7fffffffe870) at gdb/main.c:1401 #12 0x000000001001d1d8 in main (argc=3, argv=0x7fffffffece8) at gdb/gdb.c:38 ... This may be a python issue [1]. The problem doesn't happen if we use the PyConfig approach instead of the py_initialize_catch_abort approach. Fix this by using the PyConfig approach starting 3.9 (previously, starting 3.10 to avoid Py_SetProgramName deprecation in 3.11). It's possible that we have the same problem and need the same fix for 3.8, but I don't have a setup to check that. Add a todo in a comment. Tested on ppc64le-linux. Approved-By: Tom Tromey <tom@tromey.com> [1] https://github.com/python/cpython/issues/107827
2025-10-08gdb/python: cast to ui_file_style::intensity after validating valueSimon Marchi1-6/+2
When GDB is built with undefined behavior sanitizer, gdb.python/py-style.exp fails because of this: $ ./gdb -q -nx --data-directory=data-directory -ex "python filename_style = gdb.Style('filename')" -ex "python filename_style.intensity = -3" /home/simark/src/binutils-gdb/gdb/python/py-style.c:239:11: runtime error: load of value 4294967293, which is not a valid value for type 'intensity' Fix it by casting the value to ui_file_style::intensity only after validating the raw value. Change-Id: I38eb471a9cb3bfc3bb8b2c88afa76b8025e4e893 Approved-By: Tom Tromey <tom@tromey.com>
2025-10-08gdb: move core file bfd from program_space into core_targetAndrew Burgess1-11/+7
This commit moves the 'gdb_bfd_ref_ptr cbfd' out of program_space and into core_target, where it is now called m_core_bfd. I believe this change makes sense as the core_target instance holds additional information that is parsed from the core file BFD, and so storing the parsed information separately from the BFD doesn't make much sense to me. To minimise the churn in this commit, I have retained the program_space::core_bfd member function as a temporary hack. This function forwards the request to the new function get_inferior_core_bfd. This works fine for now as program_space::core_bfd is, after this commit, only called on the current_program_space. If this all seems like a total hack, then it is, but don't worry too much, the next commit will clean this all up. I was tempted to make the new function get_inferior_core_bfd, a member function of the inferior class, inferior::core_bfd. In fact, that would have been my preferred change. However, the new function needs visibility of the core_target class, which, right now is private within the corelow.c file. This shouldn't be a problem, we could just declare the member function in inferior.h, and implement the function in corelow.c. But this would mean the implementation of inferior::core_bfd, would not live in inferior.c. Previously when I've implemented member functions outside their natural home (e.g. an inferior function not in inferior.c) I've received review feedback that this is not desirable. So, for now, I've gone with a free function. I also needed to change get_current_core_target, renaming it to get_core_target, and taking an inferior as an argument. Existing call sites are updated to pass 'current_inferior ()', but get_inferior_core_bfd passes something that might not be the current inferior. There should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2025-10-07gdb: change objfiles_iterator to yield referencesSimon Marchi4-9/+9
Same rationale as the previous patches. Change-Id: I4673cedaa902c9a327d24d73508b18cf60a2cd02 Approved-By: Tom Tromey <tom@tromey.com>
2025-10-07Remove 'sys' import from frame_filters.pyTom Tromey1-2/+0
pre-commit (really flake8) points out that a recent change to frame_filters.py left an unused import. This patch fixes the problem.
2025-10-07gdb/python: make use of gdb.Style for shipped Python commandsAndrew Burgess5-14/+53
With the recent addition of the gdb.Style Python API, this commit goes through the gdb.Command sub-classes which we ship with GDB and adds some styling support. This adds 'title' style in a couple of places where we layout tables. And uses 'filename' style where we are printing filenames. While I was making these changes I've made a couple of related fixes. In 'info frame-filter', 'info missing-objfile-handlers', 'info pretty-printer', and 'info xmethod', we would sometimes print the gdb.Progspace.filename unconditionally, even though this field can sometimes be None. To better handle this case, I now check for None, and print '<no-file>' instead. We already printed that same string for the program space name in at least one other case, so this change makes things a little more consistent. I don't format the '<no-file>' string with the filename style, only if we have an actual filename does the string get formatted. The other fix I made was in 'maint info python-disassemblers'. Here I've added an extra space between the two columns in the output table. The two columns are 'Architecture' and 'Disassembler Name'. Given that one column contains a white space, it was rather confusing having a single space between columns. Luckily the tests don't depend on a single space, so nothing needs updating for this change. Additionally, in 'info frame-filter' I've updated the exception handling to use the gdb.warning function, rather than just printing a line of output. This means that should this case occur we get the neat little emoji. We have no tests that trigger this warning, and I couldn't figure out how to write one. In this end, I just hacked the Python code to raise an exception and checked the output looked reasonable. I suspect this warning might be a hard one to trigger! Approved-By: Tom Tromey <tom@tromey.com>
2025-10-07Remove some helper functions from DAP breakpoint codeTom Tromey1-19/+5
The DAP breakpoint code has some helper functions that don't really provide much value any more. This patch removes them. Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-10-06gdb/python: add Corefile.mapped_files methodAndrew Burgess1-0/+397
Add a new Corefile.mapped_files method which returns a list of gdb.CorefileMappedFile objects. Each gdb.CorefileMappedFile object represents a file that was mapped into the process when the core file was created. A gdb.CorefileMappedFile has attributes: + filename -- A string, the name of the mapped file. + build_id -- A string or None, the build-id of the mapped file if GDB could find it (None if not). + is_main_executable -- A boolean, True if this mapping is the main executable. + regions -- A list containing the regions of this file that were mapped into the process. The 'regions' list is a list of gdb.CorefileMappedFileRegion objects, each of these objects has the following attributes: + start -- the start address within the inferior. + end -- the end address within the inferior. + file_offset -- the offset within the mapped file for this mapping. There are docs and tests. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32844 Approved-By: Tom Tromey <tom@tromey.com>
2025-10-06gdb/python: introduce gdb.Corefile APIAndrew Burgess3-0/+317
This commit starts adding some core file related features to the Python API. In this initial commit I've tried to keep the changes as small as possible for easy review. There's a new Python class gdb.Corefile, which represents a loaded core file. This API doesn't allow the user to create their own gdb.Corefile objects, a core file must be loaded using the 'core-file' command, then a gdb.Corefile object can be obtained by querying the inferior in which the core file was loaded. There's a new attribute gdb.Inferior.corefile, this is None when no core file is loaded, or contains a gdb.Corefile object if a core file has been loaded. Currently, the gdb.Corefile object has one attribute, and one method, these are: gdb.Corefile.filename -- the file name of the loaded core file. gdb.Corefile.is_valid() -- indicates if a gdb.Corefile object is valid or not. See notes below. A gdb.Corefile object is only valid while the corresponding core file is loaded into an inferior. Unloading the core file, or loading a different one will cause a gdb.Corefile object to become invalid. For example: (gdb) core-file /tmp/core.54313 ... snip ... (gdb) python core=gdb.selected_inferior().corefile (gdb) python print(core) <gdb.Corefile inferior=1 filename='/tmp/core.54313'> (gdb) python print(core.is_valid()) True (gdb) core-file No core file now. (gdb) python print(core) <gdb.Corefile (invalid)> (gdb) python print(core.is_valid()) False (gdb) In order to track changes to the core file, there is a new observable 'core_file_changed', which accounts for the changes in corelow.c, observable,c, and observable.h. Currently, this observable is not visible as a Python event. I chose to access the core file via the inferior even though the core file BFD object is actually stored within the program_space. As such, it might seem that the natural choice would be to add the attribute as gdb.Progspace.corefile. For background reading on my choice, please see: https://inbox.sourceware.org/gdb-patches/577f2c47793acb501c2611c0e6c7ea379f774830.1668789658.git.aburgess@redhat.com This patch was never merged, it is still on my backlog, but the observation in that work is that some targets are not really shareable. For example, the core_target (corelow.c) stores information about the loaded core file within the target instance. As such, each target instance represents a single loaded core file. Except that the BFD part of the core file is stored in the program_space, which is a little weird. During review, Tom made the observation, that maybe we should investigate moving the core file BFD into the core_target. I'm inclined to agree with this as a direction of travel. All this leaves us with two observations: 1. Currently, loading a core file into an inferior, then using 'add-inferior' will try to share the core_target between inferiors. This is broken, and can trigger GDB crashes. The obvious fix, without reworking core_target, is just to prevent this sharing, making core_target per-inferior. 2. Having the core file information split between the core_target instance, and the BFD stored in the program_space is a little weird, and is really just historical. Planning for a future where the BFD is also stored in the core_target might be wise. So, if we imagine that the BFD is (one day) moved into the core_target, and that the core_target really becomes non-shareable, then it is, I think, clearer that the corefile attribute should live on the gdb.Inferior object, not the gdb.Progspace object. There's testing for all the functionality added in this commit. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32844 Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
generated by cgit v1.1 at 2026-02-09 23:54:22 +0000