aboutsummaryrefslogtreecommitdiff
path: root/gdb/python/python-internal.h
AgeCommit message (Collapse)AuthorFilesLines
2022-10-20gdb/python: break more dependencies between gdbpy_initialize_* functionsAndrew Burgess1-0/+12
In a later commit in this series I will propose removing all of the explicit gdbpy_initialize_* calls from python.c and replace these calls with a more generic mechanism. One of the side effects of this generic mechanism is that the order in which the various Python sub-systems within GDB are initialized is no longer guaranteed. On the whole I don't think this matters, most of the sub-systems are independent of each other, though testing did reveal a few places where we did have dependencies, though I don't think those dependencies were explicitly documented in comment anywhere. This commit is similar to the previous one, and fixes the second dependency issue that I found. In this case the finish_breakpoint_object_type uses the breakpoint_object_type as its tp_base, this means that breakpoint_object_type must have been initialized with a call to PyType_Ready before finish_breakpoint_object_type can be initialized. Previously we depended on the ordering of calls to gdbpy_initialize_breakpoints and gdbpy_initialize_finishbreakpoints in python.c. After this commit a new function gdbpy_breakpoint_init_breakpoint_type exists, this function ensures that breakpoint_object_type has been initialized, and can be called from any gdbpy_initialize_* function. I feel that this change makes the dependency explicit, which I think is a good thing. There should be no user visible changes after this commit.
2022-10-10Change GDB to use frame_info_ptrTom Tromey1-3/+3
This changes GDB to use frame_info_ptr instead of frame_info * The substitution was done with multiple sequential `sed` commands: sed 's/^struct frame_info;/class frame_info_ptr;/' sed 's/struct frame_info \*/frame_info_ptr /g' - which left some issues in a few files, that were manually fixed. sed 's/\<frame_info \*/frame_info_ptr /g' sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace problems. The changed files were then manually checked and some 'sed' changes undone, some constructors and some gets were added, according to what made sense, and what Tromey originally did Co-Authored-By: Bruno Larsen <blarsen@redhat.com> Approved-by: Tom Tomey <tom@tromey.com>
2022-08-21Fix crash in gdbpy_parse_register_idTom Tromey1-1/+2
I noticed that gdbpy_parse_register_id would assert if passed a Python object of a type it was not expecting. The included test case shows this crash. This patch fixes the problem and also changes gdbpy_parse_register_id to be more "Python-like" -- it always ensures the Python error is set when it fails, and the callers now simply propagate the existing exception.
2022-07-28gdb/python: Add BreakpointLocation typeSimon Farre1-0/+2
PR python/18385 v7: This version addresses the issues pointed out by Tom. Added nullchecks for Python object creations. Changed from using PyLong_FromLong to the gdb_py-versions. Re-factored some code to make it look more cohesive. Also added the more safe Python reference count decrement PY_XDECREF, even though the BreakpointLocation type is never instantiated by the user (explicitly documented in the docs) decrementing < 0 is made impossible with the safe call. Tom pointed out that using the policy class explicitly to decrement a reference counted object was not the way to go, so this has instead been wrapped in a ref_ptr that handles that for us in blocpy_dealloc. Moved macro from py-internal to py-breakpoint.c. Renamed section at the bottom of commit message "Patch Description". v6: This version addresses the points Pedro gave in review to this patch. Added the attributes `function`, `fullname` and `thread_groups` as per request by Pedro with the argument that it more resembles the output of the MI-command "-break-list". Added documentation for these attributes. Cleaned up left overs from copy+paste in test suite, removed hard coding of line numbers where possible. Refactored some code to use more c++-y style range for loops wrt to breakpoint locations. Changed terminology, naming was very inconsistent. Used a variety of "parent", "owner". Now "owner" is the only term used, and the field in the gdb_breakpoint_location_object now also called "owner". v5: Changes in response to review by Tom Tromey: - Replaced manual INCREF/DECREF calls with gdbpy_ref ptrs in places where possible. - Fixed non-gdb style conforming formatting - Get parent of bploc increases ref count of parent. - moved bploc Python definition to py-breakpoint.c The INCREF of self in bppy_get_locations is due to the individual locations holding a reference to it's owner. This is decremented at de-alloc time. The reason why this needs to be here is, if the user writes for instance; py loc = gdb.breakpoints()[X].locations[Y] The breakpoint owner object is immediately going out of scope (GC'd/dealloced), and the location object requires it to be alive for as long as it is alive. Thanks for your review, Tom! v4: Fixed remaining doc issues as per request by Eli. v3: Rewritten commit message, shortened + reworded, added tests. Patch Description Currently, the Python API lacks the ability to query breakpoints for their installed locations, and subsequently, can't query any information about them, or enable/disable individual locations. This patch solves this by adding Python type gdb.BreakpointLocation. The type is never instantiated by the user of the Python API directly, but is produced by the gdb.Breakpoint.locations attribute returning a list of gdb.BreakpointLocation. gdb.Breakpoint.locations: The attribute for retrieving the currently installed breakpoint locations for gdb.Breakpoint. Matches behavior of the "info breakpoints" command in that it only returns the last known or currently inserted breakpoint locations. BreakpointLocation contains 7 attributes 6 read-only attributes: owner: location owner's Python companion object source: file path and line number tuple: (string, long) / None address: installed address of the location function: function name where location was set fullname: fullname where location was set thread_groups: thread groups (inferiors) where location was set. 1 writeable attribute: enabled: get/set enable/disable this location (bool) Access/calls to these, can all throw Python exceptions (documented in the online documentation), and that's due to the nature of how breakpoint locations can be invalidated "behind the scenes", either by them being removed from the original breakpoint or changed, like for instance when a new symbol file is loaded, at which point all breakpoint locations are re-created by GDB. Therefore this patch has chosen to be non-intrusive: it's up to the Python user to re-request the locations if they become invalid. Also there's event handlers that handle new object files etc, if a Python user is storing breakpoint locations in some larger state they've built up, refreshing the locations is easy and it only comes with runtime overhead when the Python user wants to use them. gdb.BreakpointLocation Python type struct "gdbpy_breakpoint_location_object" is found in python-internal.h Its definition, layout, methods and functions are found in the same file as gdb.Breakpoint (py-breakpoint.c) 1 change was also made to breakpoint.h/c to make it possible to enable and disable a bp_location* specifically, without having its LOC_NUM, as this number also can change arbitrarily behind the scenes. Updated docs & news file as per request. Testsuite: tests the .source attribute and the disabling of individual locations. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18385 Change-Id: I302c1c50a557ad59d5d18c88ca19014731d736b0
2022-07-20Handle Python 3.11 deprecation of PySys_SetPath and Py_SetProgramNameKevin Buettner1-0/+5
Python 3.11 deprecates PySys_SetPath and Py_SetProgramName. The PyConfig API replaces these and other functions. This commit uses the PyConfig API to provide equivalent functionality while also preserving support for older versions of Python, i.e. those before Python 3.8. A beta version of Python 3.11 is available in Fedora Rawhide. Both Fedora 35 and Fedora 36 use Python 3.10, while Fedora 34 still used Python 3.9. I've tested these changes on Fedora 34, Fedora 36, and rawhide, though complete testing was not possible on rawhide due to a kernel bug. That being the case, I decided to enable the newer PyConfig API by testing PY_VERSION_HEX against 0x030a0000. This corresponds to Python 3.10. We could try to use the PyConfig API for Python versions as early as 3.8, but I'm reluctant to do this as there may have been PyConfig related bugs in earlier versions which have since been fixed. Recent linux distributions should have support for Python 3.10. This should be more than adequate for testing the new Python initialization code in GDB. Information about the PyConfig API as well as the motivation behind deprecating the old interface can be found at these links: https://github.com/python/cpython/issues/88279 https://peps.python.org/pep-0587/ https://docs.python.org/3.11/c-api/init_config.html The v2 commit also addresses several problems that Simon found in the v1 version. In v1, I had used Py_DontWriteBytecodeFlag in the new initialization code, but Simon pointed out that this global configuration variable will be deprecated in Python 3.12. This version of the patch no longer uses Py_DontWriteBytecodeFlag in the new initialization code. Additionally, both Py_DontWriteBytecodeFlag and Py_IgnoreEnvironmentFlag will no longer be used when building GDB against Python 3.10 or higher. While it's true that both of these global configuration variables are deprecated in Python 3.12, it makes sense to disable their use for gdb builds against 3.10 and higher since those are the versions for which the PyConfig API is now being used by GDB. (The PyConfig API includes different mechanisms for making the same settings afforded by use of the soon-to-be deprecated global configuration variables.) Simon also noted that PyConfig_Clear() would not have be called for one of the failure paths. I've fixed that problem and also made the rest of the "bail out" code more direct. In particular, PyConfig_Clear() will always be called, both for success and failure. The v3 patch addresses some rebase conflicts related to module initialization . Commit 3acd9a692dd ("Make 'import gdb.events' work") uses PyImport_ExtendInittab instead of PyImport_AppendInittab. That commit also initializes a struct for each module to import. Both the initialization and the call to were moved ahead of the ifdefs to avoid having to replicate (at least some of) the code three times in various portions of the ifdefs. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28668 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29287
2022-07-15Expose current 'print' settings to PythonTom Tromey1-3/+10
PR python/17291 asks for access to the current print options. While I think this need is largely satisfied by the existence of Value.format_string, it seemed to me that a bit more could be done. First, while Value.format_string uses the user's settings, it does not react to temporary settings such as "print/x". This patch changes this. Second, there is no good way to examine the current settings (in particular the temporary ones in effect for just a single "print"). This patch adds this as well. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17291
2022-07-05Make 'import gdb.events' workTom Tromey1-2/+2
Pierre-Marie noticed that, while gdb.events is a Python module, it can't be imported. This patch changes how this module is created, so that it can be imported, while also ensuring that the module is always visible, just as it was in the past. This new approach required one non-obvious change -- when running gdb.base/warning.exp, where --data-directory is intentionally not found, the event registries can now be nullptr. Consequently, this patch probably also requires https://sourceware.org/pipermail/gdb-patches/2022-June/189796.html Note that this patch obsoletes https://sourceware.org/pipermail/gdb-patches/2022-June/189797.html
2022-06-15gdb/python: implement the print_insn extension language hookAndrew Burgess1-0/+23
This commit extends the Python API to include disassembler support. The motivation for this commit was to provide an API by which the user could write Python scripts that would augment the output of the disassembler. To achieve this I have followed the model of the existing libopcodes disassembler, that is, instructions are disassembled one by one. This does restrict the type of things that it is possible to do from a Python script, i.e. all additional output has to fit on a single line, but this was all I needed, and creating something more complex would, I think, require greater changes to how GDB's internal disassembler operates. The disassembler API is contained in the new gdb.disassembler module, which defines the following classes: DisassembleInfo Similar to libopcodes disassemble_info structure, has read-only properties: address, architecture, and progspace. And has methods: __init__, read_memory, and is_valid. Each time GDB wants an instruction disassembled, an instance of this class is passed to a user written disassembler function, by reading the properties, and calling the methods (and other support methods in the gdb.disassembler module) the user can perform and return the disassembly. Disassembler This is a base-class which user written disassemblers should inherit from. This base class provides base implementations of __init__ and __call__ which the user written disassembler should override. DisassemblerResult This class can be used to hold the result of a call to the disassembler, it's really just a wrapper around a string (the text of the disassembled instruction) and a length (in bytes). The user can return an instance of this class from Disassembler.__call__ to represent the newly disassembled instruction. The gdb.disassembler module also provides the following functions: register_disassembler This function registers an instance of a Disassembler sub-class as a disassembler, either for one specific architecture, or, as a global disassembler for all architectures. builtin_disassemble This provides access to GDB's builtin disassembler. A common use case that I see is augmenting the existing disassembler output. The user code can call this function to have GDB disassemble the instruction in the normal way. The user gets back a DisassemblerResult object, which they can then read in order to augment the disassembler output in any way they wish. This function also provides a mechanism to intercept the disassemblers reads of memory, thus the user can adjust what GDB sees when it is disassembling. The included documentation provides a more detailed description of the API. There is also a new CLI command added: maint info python-disassemblers This command is defined in the Python gdb.disassemblers module, and can be used to list the currently registered Python disassemblers.
2022-06-15gdb/python: convert gdbpy_err_fetch to use gdbpy_refAndrew Burgess1-13/+10
Convert the gdbpy_err_fetch class to make use of gdbpy_ref, this removes the need for manual reference count management, and allows the destructor to be removed. There should be no functional change after this commit. I think this cleanup is worth doing on its own, however, in a later commit I will want to copy instances of gdbpy_err_fetch, and switching to using gdbpy_ref means that I can rely on the default copy constructor, without having to add one that handles the reference counts, so this is good preparation for that upcoming change.
2022-05-28gdb/python: improve formatting of help text for user defined commandsAndrew Burgess1-0/+21
Consider this command defined in Python (in the file test-cmd.py): class test_cmd (gdb.Command): """ This is the first line. Indented second line. This is the third line. """ def __init__ (self): super ().__init__ ("test-cmd", gdb.COMMAND_OBSCURE) def invoke (self, arg, from_tty): print ("In test-cmd") test_cmd() Now, within a GDB session: (gdb) source test-cmd.py (gdb) help test-cmd This is the first line. Indented second line. This is the third line. (gdb) I think there's three things wrong here: 1. The leading blank line, 2. The trailing blank line, and 3. Every line is indented from the left edge slightly. The problem of course, is that GDB is using the Python doc string verbatim as its help text. While the user has formatted the help text so that it appears clear within the .py file, this means that the text appear less well formatted when displayed in the "help" output. The same problem can be observed for gdb.Parameter objects in their set/show output. In this commit I aim to improve the "help" output for commands and parameters. To do this I have added gdbpy_fix_doc_string_indentation, a new function that rewrites the doc string text following the following rules: 1. Leading blank lines are removed, 2. Trailing blank lines are removed, and 3. Leading whitespace is removed in a "smart" way such that the relative indentation of lines is retained. With this commit in place the above example now looks like this: (gdb) source ~/tmp/test-cmd.py (gdb) help test-cmd This is the first line. Indented second line. This is the third line. (gdb) Which I think is much neater. Notice that the indentation of the second line is retained. Any blank lines within the help text (not leading or trailing) will be retained. I've added a NEWS entry to note that there has been a change in behaviour, but I didn't update the manual. The existing manual is suitably vague about how the doc string is used, so I think the new behaviour is covered just as well by the existing text.
2022-03-23gdb/python: remove Python 2/3 compatibility macrosSimon Marchi1-22/+0
New in this version: - Rebase on master, fix a few more issues that appeared. python-internal.h contains a number of macros that helped make the code work with both Python 2 and 3. Remove them and adjust the code to use the Python 3 functions. Change-Id: I99a3d80067fb2d65de4f69f6473ba6ffd16efb2d
2022-03-23gdb/python: remove Python 2 supportSimon Marchi1-10/+0
New in this version: - Add a PY_MAJOR_VERSION check in configure.ac / AC_TRY_LIBPYTHON. If the user passes --with-python=python2, this will cause a configure failure saying that GDB only supports Python 3. Support for Python 2 is a maintenance burden for any patches touching Python support. Among others, the differences between Python 2 and 3 string and integer types are subtle. It requires a lot of effort and thinking to get something that behaves correctly on both. And that's if the author and reviewer of the patch even remember to test with Python 2. See this thread for an example: https://sourceware.org/pipermail/gdb-patches/2021-December/184260.html So, remove Python 2 support. Update the documentation to state that GDB can be built against Python 3 (as opposed to Python 2 or 3). Update all the spots that use: - sys.version_info - IS_PY3K - PY_MAJOR_VERSION - gdb_py_is_py3k ... to only keep the Python 3 portions and drop the use of some now-removed compatibility macros. I did not update the configure script more than just removing the explicit references to Python 2. We could maybe do more there, like check the Python version and reject it if that version is not supported. Otherwise (with this patch), things will only fail at compile time, so it won't really be clear to the user that they are trying to use an unsupported Python version. But I'm a bit lost in the configure code that checks for Python, so I kept that for later. Change-Id: I75b0f79c148afbe3c07ac664cfa9cade052c0c62
2022-03-22gdb/python: add gdb.format_address functionAndrew Burgess1-0/+16
Add a new function, gdb.format_address, which is a wrapper around GDB's print_address function. This method takes an address, and returns a string with the format: ADDRESS <SYMBOL+OFFSET> Where, ADDRESS is the original address, formatted as hexadecimal, SYMBOL is a symbol with an address lower than ADDRESS, and OFFSET is the offset from SYMBOL to ADDRESS in decimal. If there's no SYMBOL suitably close to ADDRESS then the <SYMBOL+OFFSET> part is not included. This is useful if a user wants to write a Python script that pretty-prints addresses, the user no longer needs to do manual symbol lookup, or worry about correctly formatting addresses. Additionally, there are some settings that effect how GDB picks SYMBOL, and whether the file name and line number should be included with the SYMBOL name, the gdb.format_address function ensures that the users Python script also benefits from these settings. The gdb.format_address by default selects SYMBOL from the current inferiors program space, and address is formatted using the architecture for the current inferior. However, a user can also explicitly pass a program space and architecture like this: gdb.format_address(ADDRESS, PROGRAM_SPACE, ARCHITECTURE) In order to format an address for a different inferior. Notes on the implementation: In py-arch.c I extended arch_object_to_gdbarch to add an assertion for the type of the PyObject being worked on. Prior to this commit all uses of arch_object_to_gdbarch were guaranteed to pass this function a gdb.Architecture object, but, with this commit, this might not be the case. So, with this commit I've made it a requirement that the PyObject be a gdb.Architecture, and this is checked with the assert. And in order that callers from other files can check if they have a gdb.Architecture object, I've added the new function gdbpy_is_architecture. In py-progspace.c I've added two new function, the first progspace_object_to_program_space, converts a PyObject of type gdb.Progspace to the associated program_space pointer, and gdbpy_is_progspace checks if a PyObject is a gdb.Progspace or not.
2022-03-18gdb/python: remove gdb._mi_commands dictSimon Marchi1-0/+1
The motivation for this patch is the fact that py-micmd.c doesn't build with Python 2, due to PyDict_GetItemWithError being a Python 3-only function: CXX python/py-micmd.o /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’: /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’? 430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (), | ^~~~~~~~~~~~~~~~~~~~~~~ | PyDict_GetItemString A first solution to fix this would be to try to replace PyDict_GetItemWithError equivalent Python 2 code. But I looked at why we are doing this in the first place: it is to maintain the `gdb._mi_commands` Python dictionary that we use as a `name -> gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is never actually used in Python, it seems like a lot of trouble to use a Python object for this. My first idea was to replace it with a C++ map (std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While implementing this, I realized we don't really need this map at all. The mi_command_py objects registered in the main MI command table can own their backing micmdpy_object (that's a gdb.MICommand, but seen from the C++ code). To know whether an mi_command is an mi_command_py, we can use a dynamic cast. Since there's one less data structure to maintain, there are less chances of messing things up. - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is now what keeps the MICommand alive. - Set micmdpy_object::mi_command in the constructor of mi_command_py. If mi_command_py manages setting/clearing that field in swap_python_object, I think it makes sense that it also takes care of setting it initially. - Move a bunch of checks from micmdpy_install_command to swap_python_object, and make them gdb_asserts. - In micmdpy_install_command, start by doing an mi_cmd_lookup. This is needed to know whether there's a Python MI command already registered with that name. But we can already tell if there's a non-Python command registered with that name. Return an error if that happens, rather than waiting for insert_mi_cmd_entry to fail. Change the error message to "name is already in use" rather than "may already be in use", since it's more precise. I asked Andrew about the original intent of using a Python dictionary object to hold the command objects. The reason was to make sure the objects get destroyed when the Python runtime gets finalized, not later. Holding the objects in global C++ data structures and not doing anything more means that the held Python objects will be decref'd after the Python interpreter has been finalized. That's not desirable. I tried it and it indeed segfaults. Handle this by adding a gdbpy_finalize_micommands function called in finalize_python. This is the mirror of gdbpy_initialize_micommands called in do_start_initialization. In there, delete all Python MI commands. I think it makes sense to do it this way: if it was somehow possible to unload Python support from GDB in the middle of a session we'd want to unregister any Python MI command. Otherwise, these MI commands would be backed with a stale PyObject or simply nothing. Delete tests that were related to `gdb._mi_commands`. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
2022-03-14gdb/python/mi: create MI commands using pythonAndrew Burgess1-0/+13
This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2022-01-26gdb/python: add gdb.history_count functionAndrew Burgess1-0/+1
Add a new function gdb.history_count to the Python api, this function returns an integer, the number of items in GDB's value history. This is useful if you want to pull items from the history by their absolute number, for example, if you wanted to show a complete history list. Previously we could figure out how many items are in the history list by trying to fetch the items, and then catching the exception when the item is not available, but having this function seems nicer.
2022-01-26Change how Python architecture and language are handledTom Tromey1-4/+23
Currently, gdb's Python layer captures the current architecture and language when "entering" Python code. This has some undesirable effects, and so this series changes how this is handled. First, there is code like this: gdbpy_enter enter_py (python_gdbarch, python_language); This is incorrect, because both of these are NULL when not otherwise assigned. This can cause crashes in some cases -- I've added one to the test suite. (Note that this crasher is just an example, other ones along the same lines are possible.) Second, when the language is captured in this way, it means that Python code cannot affect the current language for its own purposes. It's reasonable to want to write code like this: gdb.execute('set language mumble') ... stuff using the current language gdb.execute('set language previous-value') However, this won't actually work, because the language is captured on entry. I've added a test to show this as well. This patch changes gdb to try to avoid capturing the current values. The Python concept of the current gdbarch is only set in those few cases where a non-default value is computed or needed; and the language is not captured at all -- instead, in the cases where it's required, the current language is temporarily changed.
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker1-1/+1
This commit brings all the changes made by running gdb/copyright.py as per GDB's Start of New Year Procedure. For the avoidance of doubt, all changes in this commits were performed by the script.
2021-11-30gdb/python: introduce gdb.TargetConnection object typeAndrew Burgess1-0/+6
This commit adds a new object type gdb.TargetConnection. This new type represents a connection within GDB (a connection as displayed by 'info connections'). There's three ways to find a gdb.TargetConnection, there's a new 'gdb.connections()' function, which returns a list of all currently active connections. Or you can read the new 'connection' property on the gdb.Inferior object type, this contains the connection for that inferior (or None if the inferior has no connection, for example, it is exited). Finally, there's a new gdb.events.connection_removed event registry, this emits a new gdb.ConnectionEvent whenever a connection is removed from GDB (this can happen when all inferiors using a connection exit, though this is not always the case, depending on the connection type). The gdb.ConnectionEvent has a 'connection' property, which is the gdb.TargetConnection being removed from GDB. The gdb.TargetConnection has an 'is_valid()' method. A connection object becomes invalid when the underlying connection is removed from GDB (as discussed above, this might be when all inferiors using a connection exit, or it might be when the user explicitly replaces a connection in GDB by issuing another 'target' command). The gdb.TargetConnection has the following read-only properties: 'num': The number for this connection, 'type': e.g. 'native', 'remote', 'sim', etc 'description': The longer description as seen in the 'info connections' command output. 'details': A string or None. Extra details for the connection, for example, a remote connection's details might be 'hostname:port'.
2021-11-08gdb: remove bpstat typedef, rename bpstats to bpstatSimon Marchi1-1/+1
I don't find that the bpstat typedef, which hides a pointer, is particularly useful. In fact, it confused me many times, and I just see it as something to remember that adds cognitive load. Also, with C++, we might want to be able to pass bpstats objects by const-reference, not necessarily by pointer. So, remove the bpstat typedef and rename struct bpstats to bpstat (since it represents one bpstat, it makes sense that it is singular). Change-Id: I52e763b6e54ee666a9e045785f686d37b4f5f849
2021-10-22gdb/python: move gdb.Membuf support into a new fileAndrew Burgess1-0/+5
In a future commit I'm going to be creating gdb.Membuf objects from a new file within gdb/python/py*.c. Currently all gdb.Membuf objects are created directly within infpy_read_memory (as a result of calling gdb.Inferior.read_memory()). Initially I split out the Membuf creation code into a new function, and left the new function in gdb/python/py-inferior.c, however, it felt a little random that the Membuf creation code should live with the inferior handling code. So, then I moved all of the Membuf related code out into a new file, gdb/python/py-membuf.c, the interface is gdbpy_buffer_to_membuf, which wraps an array of bytes into a gdb.Membuf object. Most of the code is moved directly from py-inferior.c with only minor tweaks to layout and replacing NULL with nullptr, hence, I've left the copyright date on py-membuf.c as 2009-2021 to match py-inferior.c. Currently, the only user of this code is still py-inferior.c, but in later commits this will change. There should be no user visible changes after this commit.
2021-10-22gdb/python: new gdb.architecture_names functionAndrew Burgess1-0/+1
Add a new function to the Python API, gdb.architecture_names(). This function returns a list containing all of the supported architecture names within the current build of GDB. The values returned in this list are all of the possible values that can be returned from gdb.Architecture.name().
2021-10-03gdb: Introduce setting construct within cmd_list_elementLancelot SIX1-1/+1
cmd_list_element can contain a pointer to data that can be set and / or shown. This is achieved with the void* VAR member which points to the data that can be accessed, while the VAR_TYPE member (of type enum var_types) indicates how to interpret the data pointed to. With this pattern, the user of the cmd_list_element needs to know what is the storage type associated with a given VAR_TYPES in order to do the proper casting. No automatic safeguard is available to prevent miss-use of the pointer. Client code typically looks something like: switch (c->var_type) { case var_zuinteger: unsigned int v = *(unsigned int*) c->var; ... break; case var_boolean: bool v = *(bool *) c->var; ... break; ... } This patch proposes to add an abstraction around the var_types and void* pointer pair. The abstraction is meant to prevent the user from having to handle the cast and verify that the data is read or written as a type that is coherent with the setting's var_type. This is achieved by introducing the struct setting which exposes a set of templated get / set member functions. The template parameter is the type of the variable that holds the referred variable. Using those accessors allows runtime checks to be inserted in order to ensure that the data pointed to has the expected type. For example, instantiating the member functions with bool will yield something similar to: const bool &get<bool> () const { gdb_assert (m_var_type == var_boolean); gdb_assert (m_var != nullptr); return *static_cast<bool *> (m_var); } void set<bool> (const bool &var) { gdb_assert (m_var_type == var_boolean); gdb_assert (m_var != nullptr); *static_cast<bool *> (m_var) = var; } Using the new abstraction, our initial example becomes: switch (c->var_type) { case var_zuinteger: unsigned int v = c->var->get<unsigned int> (); ... break; case var_boolean: bool v = c->var->get<bool> (); ... break; ... } While the call site is still similar, the introduction of runtime checks help ensure correct usage of the data. In order to avoid turning the bulk of add_setshow_cmd_full into a templated function, and following a suggestion from Pedro Alves, a setting can be constructed from a pre validated type erased reference to a variable. This is what setting::erased_args is used for. Introducing an opaque abstraction to describe a setting will also make it possible to use callbacks to retrieve or set the value of the setting on the fly instead of pointing to a static chunk of memory. This will be done added in a later commit. Given that a cmd_list_element may or may not reference a setting, the VAR and VAR_TYPES members of the struct are replaced with a gdb::optional<setting> named VAR. Few internal function signatures have been modified to take into account this new abstraction: -The functions value_from_setting, str_value_from_setting and get_setshow_command_value_string used to have a 'cmd_list_element *' parameter but only used it for the VAR and VAR_TYPE member. They now take a 'const setting &' parameter instead. - Similarly, the 'void *' and a 'enum var_types' parameters of pascm_param_value and gdbpy_parameter_value have been replaced with a 'const setting &' parameter. No user visible change is expected after this patch. Tested on GNU/Linux x86_64, with no regression noticed. Co-authored-by: Simon Marchi <simon.marchi@polymtl.ca> Change-Id: Ie1d08c3ceb8b30b3d7bf1efe036eb8acffcd2f34
2021-09-09gdb/python: remove all uses of Py_TPFLAGS_HAVE_ITERAndrew Burgess1-1/+0
Python 2 has a bit flag Py_TPFLAGS_HAVE_ITER which can be passed as part of the tp_flags field when defining a new object type. This flag is not defined in Python 3 and so we define it to 0 in python-internal.h (when IS_PY3K is defined). The meaning of this flag is that the object has the fields tp_iter and tp_iternext. Note the use of "has" here, the flag says nothing about the values in those fields, just that the type object has the fields. In early versions of Python 2 these fields were no part of the PyTypeObject struct, they were added in version 2.2 (see https://docs.python.org/release/2.3/api/type-structs.html). And so, there could be a some code compiled out there which has a PyTypeObject structure within it that doesn't even have the tp_iter and tp_iternext fields, attempting to access these fields would be undefined behaviour. And so Python added the Py_TPFLAGS_HAVE_ITER flag. If the flag is present then Python is free to access the tp_iter and tp_iternext fields. If we consider GDB then we always assume that the tp_iter and tp_iternext fields are part of PyTypeObject. If someone was crazy enough to try and compile GDB against Python 2.1 then we'd get lots of build errors saying that we were passing too many fields when initializing PyTypeObject structures. And so, I claim, we can be sure that GDB will always be compiled with a version of Python that has the tp_iter and tp_iternext fields in PyTypeObject. Next we can look at the Py_TPFLAGS_DEFAULT flag. In Python 2, each time additional fields are added to PyTypeObject a new Py_TPFLAGS_* flag would be defined to indicate whether those flags are present or not. And, those new flags would be added to Py_TPFLAGS_DEFAULT. And so, in the latest version of Python 2 the Py_TPFLAGS_DEFAULT flag includes Py_TPFLAGS_HAVE_ITER (see https://docs.python.org/2.7/c-api/typeobj.html). In GDB we pass Py_TPFLAGS_DEFAULT as part of the tp_flags for all objects we define. And so, in this commit, I propose to remove all uses of Py_TPFLAGS_HAVE_ITER from GDB, it's simply not needed. There should be no user visible changes after this commit.
2021-09-07gdb/python: new function to add values into GDB's historyAndrew Burgess1-0/+1
The guile API has (history-append! <value>) to add values into GDB's history list. There is currently no equivalent in the Python API. This commit adds gdb.add_history(<value>) to the Python API, this function takes <value> a gdb.Value (or anything that can be passed to the constructor of gdb.Value), and adds the value it represents to GDB's history list. The index of the newly added value is returned.
2021-05-12gdb: make gdbpy_parse_command_name return a unique_xmalloc_ptrSimon Marchi1-3/+3
This avoids some manual memory management. cmdpy_init correctly transfers ownership of the name to the cmd_list_element, as it sets the name_allocated flag. However, cmdpy_init (and add_setshow_generic) doesn't, it looks like the name is just leaked. This is a bit tricky, because it actually creates two commands (one set and one show), it would take a bit of refactoring of the command code to give each their own allocated copy. For now, just keep doing what the current code does but in a more explicit fashion, with an explicit release. gdb/ChangeLog: * python/python-internal.h (gdbpy_parse_command_name): Return gdb::unique_xmalloc_ptr. * python/py-cmd.c (gdbpy_parse_command_name): Likewise. (cmdpy_init): Adjust. * python/py-param.c (parmpy_init): Adjust. (add_setshow_generic): Take gdb::unique_xmalloc_ptr, release it when done. Change-Id: Iae5bc21fe2b22f12d5f954057b0aca7ca4cd3f0d
2021-01-13gdb: bool-ify ext_lang_auto_load_enabled and friendsSimon Marchi1-1/+4
Make it and related functions return bool. Move function comments to header where applicable. gdb/ChangeLog: * auto-load.h (auto_load_gdb_scripts_enabled): Return bool, move comment here. * auto-load.c (auto_load_gdb_scripts_enabled): Return bool, move comment to header. * extension-priv.h (struct extension_language_script_ops) <auto_load_enabled>: Return bool. * extension.h (ext_lang_auto_load_enabled): Return bool, move comment here. * extension.c (ext_lang_auto_load_enabled): Return bool, move comment to header. * guile/guile-header.h (gdbscm_auto_load_enabled): Return bool, move comment here. * guile/scm-auto-load.c (gdbscm_auto_load_enabled): Return bool, move comment to header. * python/python-header.h (gdbpy_auto_load_enabled): Return bool, move comment here. * python/py-auto-load.c (gdbpy_auto_load_enabled): Return bool, move comment to header. Change-Id: I657a17d2dab77a36884a137ce9b23a2cc6d53140
2021-01-01Update copyright year range in all GDB filesJoel Brobecker1-1/+1
This commits the result of running gdb/copyright.py as per our Start of New Year procedure... gdb/ChangeLog Update copyright year range in copyright header of all GDB files.
2020-12-11Change varobj_dynamic::child_iter to unique_ptrTom Tromey1-2/+2
This changes varobj_dynamic::child_iter to be a unique_ptr, removing some manual management. gdb/ChangeLog 2020-12-11 Tom Tromey <tom@tromey.com> * varobj.c (struct varobj_dynamic) <child_iter>: Now unique_ptr. (varobj_get_iterator): Return unique_ptr. (update_dynamic_varobj_children, install_visualizer) (varobj::~varobj): Update. * python/python-internal.h (py_varobj_get_iterator): Return unique_ptr. * python/py-varobj.c (py_varobj_get_iterator): Return unique_ptr.
2020-12-04Remove redundant typedefsTom Tromey1-4/+4
I was inspired by this patch of Simon's: https://sourceware.org/pipermail/gdb-patches/2020-November/173522.html ... to remove other typedefs that are no longer necessary now that gdb uses C++. I didn't remove absolutely every one -- I didn't touch the tdep files. However, I removed many of them. In some cases, I removed an existing different struct tag. 2020-12-04 Tom Tromey <tromey@adacore.com> * linespec.c (struct linespec_token): Rename; remove typedef. * guile/scm-block.c (struct block_smob): Remove typedef. (struct block_syms_progress_smob): Likewise. * guile/scm-symbol.c (struct symbol_smob): Remove typedef. * guile/scm-symtab.c (symtab_smob): Remove typedef. (struct sal_smob): Remove typedef. * guile/scm-param.c (struct param_smob): Remove typedef. * guile/scm-progspace.c (struct pspace_smob): Rename. * guile/scm-objfile.c (struct objfile_smob): Rename. * guile/scm-iterator.c (struct iterator_smob): Rename. * guile/scm-frame.c (struct frame_smob): Rename. * guile/scm-arch.c (struct arch_smob): Rename. * guile/scm-type.c (struct field_smob): Remove typedef. (struct type_smob): Rename. * guile/scm-cmd.c (struct command_smob): Remove typedef. * guile/scm-ports.c (struct ioscm_memory_port): Remove typedef. * guile/scm-value.c (struct value_smob): Remove typedef. * guile/scm-lazy-string.c (lazy_string_smob): Remove typedef. * guile/guile-internal.h (struct scheme_variable) (struct scheme_function, struct scheme_integer_constant) (struct gdb_smob, struct chained_gdb_smob) (struct eqable_gdb_smob, arch_smob, frame_smob, iterator_smob) (objfile_smob, pspace_smob, type_smob): Remove typedef. * guile/scm-pretty-print.c (pretty_printer_smob): Remove typedef. (struct pretty_printer_worker_smob): Remove typedef. * guile/scm-exception.c (struct exception_smob): Remove typedef. * python/py-block.c (struct block_object): Remove typedef. (block_syms_iterator_object): Update. (set_block): Update. (block_syms_iterator_object): Remove typedef. * python/py-inferior.c (struct membuf_object): Remove typedef. * python/py-symtab.c (struct symtab_object): Remove typedef. (set_symtab): Update. (sal_object): Remove typedef. (set_sal): Update. * python/py-frame.c (frame_object): Remove typedef. * python/py-record-btrace.c (struct btpy_list_object): Remove typedef. * python/py-arch.c (struct arch_object): Remove typedef. * python/py-linetable.c (struct linetable_entry_object) (linetable_object, struct ltpy_iterator_object): Remove typedef. * python/py-events.h (eventregistry_object): Remove typedef. (struct events_object): Remove typedef. * python/python-internal.h (gdbpy_breakpoint_object): Remove typedef. (thread_object): Remove typedef. * python/py-progspace.c (pspace_object): Remove typedef. * python/py-value.c (struct value_object): Remove typedef. * python/py-record.h (recpy_record_object): Remove typedef. (struct recpy_element_object): Remove typedef. * python/py-lazy-string.c (lazy_string_object): Remove typedef. * python/py-objfile.c (objfile_object): Remove typedef. * python/py-cmd.c (struct cmdpy_object): Remove typedef. * python/py-type.c (type_object): Remove typedef. (typy_iterator_object): Update. (set_type): Update. (field_object): Remove typedef. (typy_iterator_object): Remove typedef. * python/py-registers.c (register_descriptor_iterator_object): Remove typedef. (struct register_descriptor_object) (struct reggroup_iterator_object, struct reggroup_object): Remove typedef. * python/py-record.c (recpy_gap_object): Remove typedef. * python/py-symbol.c (symbol_object): Remove typedef. (set_symbol): Update. * python/py-event.h (event_object): Remove typedef. * python/py-param.c (parmpy_object): Remove typedef. * python/py-instruction.c (struct py_insn_obj): Remove typedef. * python/py-unwind.c (struct pending_frame_object): Remove typedef. (unwind_info_object, struct cached_frame_info): Likewise.
2020-11-02gdb, gdbserver, gdbsupport: fix leading space vs tabs issuesSimon Marchi1-10/+10
Many spots incorrectly use only spaces for indentation (for example, there are a lot of spots in ada-lang.c). I've always found it awkward when I needed to edit one of these spots: do I keep the original wrong indentation, or do I fix it? What if the lines around it are also wrong, do I fix them too? I probably don't want to fix them in the same patch, to avoid adding noise to my patch. So I propose to fix as much as possible once and for all (hopefully). One typical counter argument for this is that it makes code archeology more difficult, because git-blame will show this commit as the last change for these lines. My counter counter argument is: when git-blaming, you often need to do "blame the file at the parent commit" anyway, to go past some other refactor that touched the line you are interested in, but is not the change you are looking for. So you already need a somewhat efficient way to do this. Using some interactive tool, rather than plain git-blame, makes this trivial. For example, I use "tig blame <file>", where going back past the commit that changed the currently selected line is one keystroke. It looks like Magit in Emacs does it too (though I've never used it). Web viewers of Github and Gitlab do it too. My point is that it won't really make archeology more difficult. The other typical counter argument is that it will cause conflicts with existing patches. That's true... but it's a one time cost, and those are not conflicts that are difficult to resolve. I have also tried "git rebase --ignore-whitespace", it seems to work well. Although that will re-introduce the faulty indentation, so one needs to take care of fixing the indentation in the patch after that (which is easy). gdb/ChangeLog: * aarch64-linux-tdep.c: Fix indentation. * aarch64-ravenscar-thread.c: Fix indentation. * aarch64-tdep.c: Fix indentation. * aarch64-tdep.h: Fix indentation. * ada-lang.c: Fix indentation. * ada-lang.h: Fix indentation. * ada-tasks.c: Fix indentation. * ada-typeprint.c: Fix indentation. * ada-valprint.c: Fix indentation. * ada-varobj.c: Fix indentation. * addrmap.c: Fix indentation. * addrmap.h: Fix indentation. * agent.c: Fix indentation. * aix-thread.c: Fix indentation. * alpha-bsd-nat.c: Fix indentation. * alpha-linux-tdep.c: Fix indentation. * alpha-mdebug-tdep.c: Fix indentation. * alpha-nbsd-tdep.c: Fix indentation. * alpha-obsd-tdep.c: Fix indentation. * alpha-tdep.c: Fix indentation. * amd64-bsd-nat.c: Fix indentation. * amd64-darwin-tdep.c: Fix indentation. * amd64-linux-nat.c: Fix indentation. * amd64-linux-tdep.c: Fix indentation. * amd64-nat.c: Fix indentation. * amd64-obsd-tdep.c: Fix indentation. * amd64-tdep.c: Fix indentation. * amd64-windows-tdep.c: Fix indentation. * annotate.c: Fix indentation. * arc-tdep.c: Fix indentation. * arch-utils.c: Fix indentation. * arch/arm-get-next-pcs.c: Fix indentation. * arch/arm.c: Fix indentation. * arm-linux-nat.c: Fix indentation. * arm-linux-tdep.c: Fix indentation. * arm-nbsd-tdep.c: Fix indentation. * arm-pikeos-tdep.c: Fix indentation. * arm-tdep.c: Fix indentation. * arm-tdep.h: Fix indentation. * arm-wince-tdep.c: Fix indentation. * auto-load.c: Fix indentation. * auxv.c: Fix indentation. * avr-tdep.c: Fix indentation. * ax-gdb.c: Fix indentation. * ax-general.c: Fix indentation. * bfin-linux-tdep.c: Fix indentation. * block.c: Fix indentation. * block.h: Fix indentation. * blockframe.c: Fix indentation. * bpf-tdep.c: Fix indentation. * break-catch-sig.c: Fix indentation. * break-catch-syscall.c: Fix indentation. * break-catch-throw.c: Fix indentation. * breakpoint.c: Fix indentation. * breakpoint.h: Fix indentation. * bsd-uthread.c: Fix indentation. * btrace.c: Fix indentation. * build-id.c: Fix indentation. * buildsym-legacy.h: Fix indentation. * buildsym.c: Fix indentation. * c-typeprint.c: Fix indentation. * c-valprint.c: Fix indentation. * c-varobj.c: Fix indentation. * charset.c: Fix indentation. * cli/cli-cmds.c: Fix indentation. * cli/cli-decode.c: Fix indentation. * cli/cli-decode.h: Fix indentation. * cli/cli-script.c: Fix indentation. * cli/cli-setshow.c: Fix indentation. * coff-pe-read.c: Fix indentation. * coffread.c: Fix indentation. * compile/compile-cplus-types.c: Fix indentation. * compile/compile-object-load.c: Fix indentation. * compile/compile-object-run.c: Fix indentation. * completer.c: Fix indentation. * corefile.c: Fix indentation. * corelow.c: Fix indentation. * cp-abi.h: Fix indentation. * cp-namespace.c: Fix indentation. * cp-support.c: Fix indentation. * cp-valprint.c: Fix indentation. * cris-linux-tdep.c: Fix indentation. * cris-tdep.c: Fix indentation. * darwin-nat-info.c: Fix indentation. * darwin-nat.c: Fix indentation. * darwin-nat.h: Fix indentation. * dbxread.c: Fix indentation. * dcache.c: Fix indentation. * disasm.c: Fix indentation. * dtrace-probe.c: Fix indentation. * dwarf2/abbrev.c: Fix indentation. * dwarf2/attribute.c: Fix indentation. * dwarf2/expr.c: Fix indentation. * dwarf2/frame.c: Fix indentation. * dwarf2/index-cache.c: Fix indentation. * dwarf2/index-write.c: Fix indentation. * dwarf2/line-header.c: Fix indentation. * dwarf2/loc.c: Fix indentation. * dwarf2/macro.c: Fix indentation. * dwarf2/read.c: Fix indentation. * dwarf2/read.h: Fix indentation. * elfread.c: Fix indentation. * eval.c: Fix indentation. * event-top.c: Fix indentation. * exec.c: Fix indentation. * exec.h: Fix indentation. * expprint.c: Fix indentation. * f-lang.c: Fix indentation. * f-typeprint.c: Fix indentation. * f-valprint.c: Fix indentation. * fbsd-nat.c: Fix indentation. * fbsd-tdep.c: Fix indentation. * findvar.c: Fix indentation. * fork-child.c: Fix indentation. * frame-unwind.c: Fix indentation. * frame-unwind.h: Fix indentation. * frame.c: Fix indentation. * frv-linux-tdep.c: Fix indentation. * frv-tdep.c: Fix indentation. * frv-tdep.h: Fix indentation. * ft32-tdep.c: Fix indentation. * gcore.c: Fix indentation. * gdb_bfd.c: Fix indentation. * gdbarch.sh: Fix indentation. * gdbarch.c: Re-generate * gdbarch.h: Re-generate. * gdbcore.h: Fix indentation. * gdbthread.h: Fix indentation. * gdbtypes.c: Fix indentation. * gdbtypes.h: Fix indentation. * glibc-tdep.c: Fix indentation. * gnu-nat.c: Fix indentation. * gnu-nat.h: Fix indentation. * gnu-v2-abi.c: Fix indentation. * gnu-v3-abi.c: Fix indentation. * go32-nat.c: Fix indentation. * guile/guile-internal.h: Fix indentation. * guile/scm-cmd.c: Fix indentation. * guile/scm-frame.c: Fix indentation. * guile/scm-iterator.c: Fix indentation. * guile/scm-math.c: Fix indentation. * guile/scm-ports.c: Fix indentation. * guile/scm-pretty-print.c: Fix indentation. * guile/scm-value.c: Fix indentation. * h8300-tdep.c: Fix indentation. * hppa-linux-nat.c: Fix indentation. * hppa-linux-tdep.c: Fix indentation. * hppa-nbsd-nat.c: Fix indentation. * hppa-nbsd-tdep.c: Fix indentation. * hppa-obsd-nat.c: Fix indentation. * hppa-tdep.c: Fix indentation. * hppa-tdep.h: Fix indentation. * i386-bsd-nat.c: Fix indentation. * i386-darwin-nat.c: Fix indentation. * i386-darwin-tdep.c: Fix indentation. * i386-dicos-tdep.c: Fix indentation. * i386-gnu-nat.c: Fix indentation. * i386-linux-nat.c: Fix indentation. * i386-linux-tdep.c: Fix indentation. * i386-nto-tdep.c: Fix indentation. * i386-obsd-tdep.c: Fix indentation. * i386-sol2-nat.c: Fix indentation. * i386-tdep.c: Fix indentation. * i386-tdep.h: Fix indentation. * i386-windows-tdep.c: Fix indentation. * i387-tdep.c: Fix indentation. * i387-tdep.h: Fix indentation. * ia64-libunwind-tdep.c: Fix indentation. * ia64-libunwind-tdep.h: Fix indentation. * ia64-linux-nat.c: Fix indentation. * ia64-linux-tdep.c: Fix indentation. * ia64-tdep.c: Fix indentation. * ia64-tdep.h: Fix indentation. * ia64-vms-tdep.c: Fix indentation. * infcall.c: Fix indentation. * infcmd.c: Fix indentation. * inferior.c: Fix indentation. * infrun.c: Fix indentation. * iq2000-tdep.c: Fix indentation. * language.c: Fix indentation. * linespec.c: Fix indentation. * linux-fork.c: Fix indentation. * linux-nat.c: Fix indentation. * linux-tdep.c: Fix indentation. * linux-thread-db.c: Fix indentation. * lm32-tdep.c: Fix indentation. * m2-lang.c: Fix indentation. * m2-typeprint.c: Fix indentation. * m2-valprint.c: Fix indentation. * m32c-tdep.c: Fix indentation. * m32r-linux-tdep.c: Fix indentation. * m32r-tdep.c: Fix indentation. * m68hc11-tdep.c: Fix indentation. * m68k-bsd-nat.c: Fix indentation. * m68k-linux-nat.c: Fix indentation. * m68k-linux-tdep.c: Fix indentation. * m68k-tdep.c: Fix indentation. * machoread.c: Fix indentation. * macrocmd.c: Fix indentation. * macroexp.c: Fix indentation. * macroscope.c: Fix indentation. * macrotab.c: Fix indentation. * macrotab.h: Fix indentation. * main.c: Fix indentation. * mdebugread.c: Fix indentation. * mep-tdep.c: Fix indentation. * mi/mi-cmd-catch.c: Fix indentation. * mi/mi-cmd-disas.c: Fix indentation. * mi/mi-cmd-env.c: Fix indentation. * mi/mi-cmd-stack.c: Fix indentation. * mi/mi-cmd-var.c: Fix indentation. * mi/mi-cmds.c: Fix indentation. * mi/mi-main.c: Fix indentation. * mi/mi-parse.c: Fix indentation. * microblaze-tdep.c: Fix indentation. * minidebug.c: Fix indentation. * minsyms.c: Fix indentation. * mips-linux-nat.c: Fix indentation. * mips-linux-tdep.c: Fix indentation. * mips-nbsd-tdep.c: Fix indentation. * mips-tdep.c: Fix indentation. * mn10300-linux-tdep.c: Fix indentation. * mn10300-tdep.c: Fix indentation. * moxie-tdep.c: Fix indentation. * msp430-tdep.c: Fix indentation. * namespace.h: Fix indentation. * nat/fork-inferior.c: Fix indentation. * nat/gdb_ptrace.h: Fix indentation. * nat/linux-namespaces.c: Fix indentation. * nat/linux-osdata.c: Fix indentation. * nat/netbsd-nat.c: Fix indentation. * nat/x86-dregs.c: Fix indentation. * nbsd-nat.c: Fix indentation. * nbsd-tdep.c: Fix indentation. * nios2-linux-tdep.c: Fix indentation. * nios2-tdep.c: Fix indentation. * nto-procfs.c: Fix indentation. * nto-tdep.c: Fix indentation. * objfiles.c: Fix indentation. * objfiles.h: Fix indentation. * opencl-lang.c: Fix indentation. * or1k-tdep.c: Fix indentation. * osabi.c: Fix indentation. * osabi.h: Fix indentation. * osdata.c: Fix indentation. * p-lang.c: Fix indentation. * p-typeprint.c: Fix indentation. * p-valprint.c: Fix indentation. * parse.c: Fix indentation. * ppc-linux-nat.c: Fix indentation. * ppc-linux-tdep.c: Fix indentation. * ppc-nbsd-nat.c: Fix indentation. * ppc-nbsd-tdep.c: Fix indentation. * ppc-obsd-nat.c: Fix indentation. * ppc-ravenscar-thread.c: Fix indentation. * ppc-sysv-tdep.c: Fix indentation. * ppc64-tdep.c: Fix indentation. * printcmd.c: Fix indentation. * proc-api.c: Fix indentation. * producer.c: Fix indentation. * producer.h: Fix indentation. * prologue-value.c: Fix indentation. * prologue-value.h: Fix indentation. * psymtab.c: Fix indentation. * python/py-arch.c: Fix indentation. * python/py-bpevent.c: Fix indentation. * python/py-event.c: Fix indentation. * python/py-event.h: Fix indentation. * python/py-finishbreakpoint.c: Fix indentation. * python/py-frame.c: Fix indentation. * python/py-framefilter.c: Fix indentation. * python/py-inferior.c: Fix indentation. * python/py-infthread.c: Fix indentation. * python/py-objfile.c: Fix indentation. * python/py-prettyprint.c: Fix indentation. * python/py-registers.c: Fix indentation. * python/py-signalevent.c: Fix indentation. * python/py-stopevent.c: Fix indentation. * python/py-stopevent.h: Fix indentation. * python/py-threadevent.c: Fix indentation. * python/py-tui.c: Fix indentation. * python/py-unwind.c: Fix indentation. * python/py-value.c: Fix indentation. * python/py-xmethods.c: Fix indentation. * python/python-internal.h: Fix indentation. * python/python.c: Fix indentation. * ravenscar-thread.c: Fix indentation. * record-btrace.c: Fix indentation. * record-full.c: Fix indentation. * record.c: Fix indentation. * reggroups.c: Fix indentation. * regset.h: Fix indentation. * remote-fileio.c: Fix indentation. * remote.c: Fix indentation. * reverse.c: Fix indentation. * riscv-linux-tdep.c: Fix indentation. * riscv-ravenscar-thread.c: Fix indentation. * riscv-tdep.c: Fix indentation. * rl78-tdep.c: Fix indentation. * rs6000-aix-tdep.c: Fix indentation. * rs6000-lynx178-tdep.c: Fix indentation. * rs6000-nat.c: Fix indentation. * rs6000-tdep.c: Fix indentation. * rust-lang.c: Fix indentation. * rx-tdep.c: Fix indentation. * s12z-tdep.c: Fix indentation. * s390-linux-tdep.c: Fix indentation. * score-tdep.c: Fix indentation. * ser-base.c: Fix indentation. * ser-mingw.c: Fix indentation. * ser-uds.c: Fix indentation. * ser-unix.c: Fix indentation. * serial.c: Fix indentation. * sh-linux-tdep.c: Fix indentation. * sh-nbsd-tdep.c: Fix indentation. * sh-tdep.c: Fix indentation. * skip.c: Fix indentation. * sol-thread.c: Fix indentation. * solib-aix.c: Fix indentation. * solib-darwin.c: Fix indentation. * solib-frv.c: Fix indentation. * solib-svr4.c: Fix indentation. * solib.c: Fix indentation. * source.c: Fix indentation. * sparc-linux-tdep.c: Fix indentation. * sparc-nbsd-tdep.c: Fix indentation. * sparc-obsd-tdep.c: Fix indentation. * sparc-ravenscar-thread.c: Fix indentation. * sparc-tdep.c: Fix indentation. * sparc64-linux-tdep.c: Fix indentation. * sparc64-nbsd-tdep.c: Fix indentation. * sparc64-obsd-tdep.c: Fix indentation. * sparc64-tdep.c: Fix indentation. * stabsread.c: Fix indentation. * stack.c: Fix indentation. * stap-probe.c: Fix indentation. * stubs/ia64vms-stub.c: Fix indentation. * stubs/m32r-stub.c: Fix indentation. * stubs/m68k-stub.c: Fix indentation. * stubs/sh-stub.c: Fix indentation. * stubs/sparc-stub.c: Fix indentation. * symfile-mem.c: Fix indentation. * symfile.c: Fix indentation. * symfile.h: Fix indentation. * symmisc.c: Fix indentation. * symtab.c: Fix indentation. * symtab.h: Fix indentation. * target-float.c: Fix indentation. * target.c: Fix indentation. * target.h: Fix indentation. * tic6x-tdep.c: Fix indentation. * tilegx-linux-tdep.c: Fix indentation. * tilegx-tdep.c: Fix indentation. * top.c: Fix indentation. * tracefile-tfile.c: Fix indentation. * tracepoint.c: Fix indentation. * tui/tui-disasm.c: Fix indentation. * tui/tui-io.c: Fix indentation. * tui/tui-regs.c: Fix indentation. * tui/tui-stack.c: Fix indentation. * tui/tui-win.c: Fix indentation. * tui/tui-winsource.c: Fix indentation. * tui/tui.c: Fix indentation. * typeprint.c: Fix indentation. * ui-out.h: Fix indentation. * unittests/copy_bitwise-selftests.c: Fix indentation. * unittests/memory-map-selftests.c: Fix indentation. * utils.c: Fix indentation. * v850-tdep.c: Fix indentation. * valarith.c: Fix indentation. * valops.c: Fix indentation. * valprint.c: Fix indentation. * valprint.h: Fix indentation. * value.c: Fix indentation. * value.h: Fix indentation. * varobj.c: Fix indentation. * vax-tdep.c: Fix indentation. * windows-nat.c: Fix indentation. * windows-tdep.c: Fix indentation. * xcoffread.c: Fix indentation. * xml-syscall.c: Fix indentation. * xml-tdesc.c: Fix indentation. * xstormy16-tdep.c: Fix indentation. * xtensa-config.c: Fix indentation. * xtensa-linux-nat.c: Fix indentation. * xtensa-linux-tdep.c: Fix indentation. * xtensa-tdep.c: Fix indentation. gdbserver/ChangeLog: * ax.cc: Fix indentation. * dll.cc: Fix indentation. * inferiors.h: Fix indentation. * linux-low.cc: Fix indentation. * linux-nios2-low.cc: Fix indentation. * linux-ppc-ipa.cc: Fix indentation. * linux-ppc-low.cc: Fix indentation. * linux-x86-low.cc: Fix indentation. * linux-xtensa-low.cc: Fix indentation. * regcache.cc: Fix indentation. * server.cc: Fix indentation. * tracepoint.cc: Fix indentation. gdbsupport/ChangeLog: * common-exceptions.h: Fix indentation. * event-loop.cc: Fix indentation. * fileio.cc: Fix indentation. * filestuff.cc: Fix indentation. * gdb-dlfcn.cc: Fix indentation. * gdb_string_view.h: Fix indentation. * job-control.cc: Fix indentation. * signals.cc: Fix indentation. Change-Id: I4bad7ae6be0fbe14168b8ebafb98ffe14964a695
2020-09-15Don't use PyInt_FromLongTom Tromey1-1/+0
Avoid the use of PyInt_FromLong, preferring gdb_py_object_from_longest instead. I found found another spot that was incorrectly handling errors (see gdbpy_create_ptid_object) while writing this patch; it is fixed here. gdb/ChangeLog 2020-09-15 Tom Tromey <tromey@adacore.com> * python/python-internal.h (PyInt_FromLong): Remove define. * python/py-value.c (convert_value_from_python): Use gdb_py_object_from_longest. * python/py-type.c (typy_get_code): Use gdb_py_object_from_longest. * python/py-symtab.c (salpy_get_line): Use gdb_py_object_from_longest. * python/py-symbol.c (sympy_get_addr_class, sympy_line): Use gdb_py_object_from_longest. * python/py-record.c (recpy_gap_reason_code): Use gdb_py_object_from_longest. * python/py-record-btrace.c (recpy_bt_insn_size) (recpy_bt_func_level, btpy_list_count): Use gdb_py_object_from_longest. * python/py-infthread.c (gdbpy_create_ptid_object): Use gdb_py_object_from_longest. Fix error handling. * python/py-framefilter.c (bootstrap_python_frame_filters): Use gdb_py_object_from_longest. * python/py-frame.c (frapy_type, frapy_unwind_stop_reason): Use gdb_py_object_from_longest. * python/py-breakpoint.c (bppy_get_type, bppy_get_number) (bppy_get_thread, bppy_get_task, bppy_get_hit_count) (bppy_get_ignore_count): Use gdb_py_object_from_longest.
2020-09-15Don't use gdb_py_long_from_ulongestTom Tromey1-2/+0
Remove the gdb_py_long_from_ulongest defines and change the Python layer to prefer gdb_py_object_from_ulongest. While writing this I noticed that the error handling in archpy_disassemble was incorrect -- it could call PyDict_SetItemString with a NULL value. This patch also fixes this bug. gdb/ChangeLog 2020-09-15 Tom Tromey <tromey@adacore.com> * python/python-internal.h (gdb_py_long_from_ulongest): Remove defines. * python/py-value.c (valpy_long): Use gdb_py_object_from_ulongest. * python/py-symtab.c (salpy_get_pc): Use gdb_py_object_from_ulongest. (salpy_get_last): Likewise. * python/py-record-btrace.c (recpy_bt_insn_pc): Use gdb_py_object_from_ulongest. * python/py-lazy-string.c (stpy_get_address): Use gdb_py_object_from_ulongest. * python/py-frame.c (frapy_pc): Use gdb_py_object_from_ulongest. * python/py-arch.c (archpy_disassemble): Use gdb_py_object_from_ulongest and gdb_py_object_from_longest. Fix error handling.
2020-09-15Don't use gdb_py_long_from_longestTom Tromey1-2/+0
Change the Python layer to avoid gdb_py_long_from_longest, and remove the defines. gdb/ChangeLog 2020-09-15 Tom Tromey <tromey@adacore.com> * python/python-internal.h (gdb_py_long_from_longest): Remove defines. * python/py-value.c (valpy_long): Use gdb_py_object_from_longest. * python/py-type.c (convert_field, typy_get_sizeof): Use gdb_py_object_from_longest. * python/py-record-btrace.c (btpy_list_index): Use gdb_py_object_from_longest.
2020-09-15Don't use PyInt_FromSsize_tTom Tromey1-1/+0
Change the Python layer to avoid PyInt_FromSsize_t, and remove the compatibility define. gdb/ChangeLog 2020-09-15 Tom Tromey <tromey@adacore.com> * python/python-internal.h (PyInt_FromSsize_t): Remove define. * python/py-record.c (recpy_element_number): Use gdb_py_object_from_longest. (recpy_gap_number): Likewise.
2020-07-28gdb/python: make more use of RegisterDescriptorsAndrew Burgess1-0/+19
This commit unifies all of the Python register lookup code (used by Frame.read_register, PendingFrame.read_register, and gdb.UnwindInfo.add_saved_register), and adds support for using a gdb.RegisterDescriptor for register lookup. Currently the register unwind code (PendingFrame and UnwindInfo) allow registers to be looked up either by name, or by GDB's internal number. I suspect the number was added for performance reasons, when unwinding we don't want to repeatedly map from name to number for every unwind. However, this kind-of sucks, it means Python scripts could include GDB's internal register numbers, and if we ever change this numbering in the future users scripts will break in unexpected ways. Meanwhile, the Frame.read_register method only supports accessing registers using a string, the register name. This commit unifies all of the register to register-number lookup code in our Python bindings, and adds a third choice into the mix, the use of gdb.RegisterDescriptor. The register descriptors can be looked up by name, but once looked up, they contain GDB's register number, and so provide all of the performance benefits of using a register number directly. However, as they are looked up by name we are no longer tightly binding the Python API to GDB's internal numbering scheme. As we may already have scripts in the wild that are using the register numbers directly I have kept support for this in the API, but I have listed this method last in the manual, and I have tried to stress that this is NOT a good method to use and that users should use either a string or register descriptor approach. After this commit all existing Python code should function as before, but users now have new options for how to identify registers. gdb/ChangeLog: * python/py-frame.c: Remove 'user-regs.h' include. (frapy_read_register): Rewrite to make use of gdbpy_parse_register_id. * python/py-registers.c (gdbpy_parse_register_id): New function, moved here from python/py-unwind.c. Updated the return type, and also accepts register descriptor objects. * python/py-unwind.c: Remove 'user-regs.h' include. (pyuw_parse_register_id): Moved to python/py-registers.c. (unwind_infopy_add_saved_register): Update to use gdbpy_parse_register_id. (pending_framepy_read_register): Likewise. * python/python-internal.h (gdbpy_parse_register_id): Declare. gdb/testsuite/ChangeLog: * gdb.python/py-unwind.py: Update to make use of a register descriptor. gdb/doc/ChangeLog: * python.texi (Unwinding Frames in Python): Update descriptions for PendingFrame.read_register and gdb.UnwindInfo.add_saved_register. (Frames In Python): Update description of Frame.read_register.
2020-07-06gdb/python: New method to access list of register groupsAndrew Burgess1-0/+1
Add a new method gdb.Architecture.register_groups which returns a new object of type gdb.RegisterGroupsIterator. This new iterator then returns objects of type gdb.RegisterGroup. Each gdb.RegisterGroup object just wraps a single reggroup pointer, and (currently) has just one read-only property 'name' that is a string, the name of the register group. As with the previous commit (adding gdb.RegisterDescriptor) I made gdb.RegisterGroup an object rather than just a string in case we want to add additional properties in the future. gdb/ChangeLog: * NEWS: Mention additions to Python API. * python/py-arch.c (archpy_register_groups): New function. (arch_object_methods): Add 'register_groups' method. * python/py-registers.c (reggroup_iterator_object): New struct. (reggroup_object): New struct. (gdbpy_new_reggroup): New function. (gdbpy_reggroup_to_string): New function. (gdbpy_reggroup_name): New function. (gdbpy_reggroup_iter): New function. (gdbpy_reggroup_iter_next): New function. (gdbpy_new_reggroup_iterator): New function (gdbpy_initialize_registers): Register new types. (reggroup_iterator_object_type): Define new Python type. (gdbpy_reggroup_getset): New static global. (reggroup_object_type): Define new Python type. * python/python-internal.h gdb/testsuite/ChangeLog: * gdb.python/py-arch-reg-groups.exp: New file. gdb/doc/ChangeLog: * gdb.texi (Registers): Add @anchor for 'info registers <reggroup>' command. * python.texi (Architectures In Python): Document new register_groups method. (Registers In Python): Document two new object types related to register groups.
2020-07-06gdb/python: Add gdb.Architecture.registers methodAndrew Burgess1-0/+5
This commit adds a new method gdb.Architecture.registers that returns an object of the new type gdb.RegisterDescriptorIterator. This iterator returns objects of the new type gdb.RegisterDescriptor. A RegisterDescriptor is not a way to read the value of a register, this is already covered by Frame.read_register, a RegisterDescriptor is simply a way to discover from Python, which registers are available for a given architecture. I did consider just returning a string, the name of each register, instead of a RegisterDescriptor, however, I'm aware that it we don't want to break the existing Python API in any way, so if I return just a string now, but in the future we want more information about a register then we would have to add a second API to get that information. By going straight to a descriptor object now, it is easy to add additional properties in the future should we wish to. Right now the only property of a register that a user can access is the name of the register. In future we might want to be able to ask the register about is register groups, or its type. gdb/ChangeLog: * Makefile.in (SUBDIR_PYTHON_SRCS): Add py-registers.c * python/py-arch.c (archpy_registers): New function. (arch_object_methods): Add 'registers' method. * python/py-registers.c: New file. * python/python-internal.h (gdbpy_new_register_descriptor_iterator): Declare. (gdbpy_initialize_registers): Declare. * python/python.c (do_start_initialization): Call gdbpy_initialize_registers. * NEWS: Mention additions to the Python API. gdb/testsuite/ChangeLog: * gdb.python/py-arch-reg-names.exp: New file. gdb/doc/ChangeLog: * python.texi (Python API): Add new section the menu. (Frames In Python): Add new @anchor. (Architectures In Python): Document new registers method. (Registers In Python): New section.
2020-03-13Change extension language pretty-printers to use value APITom Tromey1-3/+2
This changes the extension language pretty-printers to use the value API. Note that new functions were needed, for both Guile and Python. Currently both languages always wrap values by removing the values from the value chain. This makes sense to avoid strange behavior with watchpoints, and to avoid excessive memory use. However, when printing, it's important to leave the passed-in value untouched, in case pretty-printing does nothing -- that way the caller can still access it. gdb/ChangeLog 2020-03-13 Tom Tromey <tom@tromey.com> * valprint.c (do_val_print): Update. * python/python-internal.h (gdbpy_apply_val_pretty_printer): Take a struct value. (value_to_value_object_no_release): Declare. * python/py-value.c (value_to_value_object_no_release): New function. * python/py-prettyprint.c (gdbpy_apply_val_pretty_printer): Take a struct value. * guile/scm-value.c (vlscm_scm_from_value_no_release): New function. * guile/scm-pretty-print.c (gdbscm_apply_val_pretty_printer): Take a struct value. * guile/guile-internal.h (vlscm_scm_from_value_no_release): Declare. (gdbscm_apply_val_pretty_printer): Take a struct value. * extension.h (apply_ext_lang_val_pretty_printer): Take a struct value. * extension.c (apply_ext_lang_val_pretty_printer): Take a struct value. * extension-priv.h (struct extension_language_ops) <apply_val_pretty_printer>: Take a struct value. * cp-valprint.c (cp_print_value): Create a struct value. (cp_print_value): Update.
2020-02-22Allow TUI windows in PythonTom Tromey1-0/+4
This patch adds support for writing new TUI windows in Python. 2020-02-22 Tom Tromey <tom@tromey.com> * NEWS: Add entry for gdb.register_window_type. * tui/tui-layout.h (window_factory): New typedef. (tui_register_window): Declare. * tui/tui-layout.c (saved_tui_windows): New global. (tui_apply_current_layout): Use it. (tui_register_window): New function. * python/python.c (do_start_initialization): Call gdbpy_initialize_tui. (python_GdbMethods): Add "register_window_type" function. * python/python-internal.h (gdbpy_register_tui_window) (gdbpy_initialize_tui): Declare. * python/py-tui.c: New file. * Makefile.in (SUBDIR_PYTHON_SRCS): Add py-tui.c. gdb/doc/ChangeLog 2020-02-22 Tom Tromey <tom@tromey.com> * python.texi (Python API): Add menu item. (TUI Windows In Python): New node. gdb/testsuite/ChangeLog 2020-02-22 Tom Tromey <tom@tromey.com> * gdb.python/tui-window.exp: New file. * gdb.python/tui-window.py: New file. Change-Id: I85fbfb923a1840450a00a7dce113a05d7f048baa
2020-01-01Update copyright year range in all GDB files.Joel Brobecker1-1/+1
gdb/ChangeLog: Update copyright year range in all GDB files.
2019-11-10gdb/python: Introduce gdb.lookup_static_symbolsAndrew Burgess1-0/+2
If gdb.lookup_static_symbol is going to return a single symbol then it makes sense (I think) for it to return a context sensitive choice of symbol, that is the global static symbol that would be visible to the program at that point. However, if the user of the python API wants to instead get a consistent set of global static symbols, no matter where they stop, then they have to instead consider all global static symbols with a given name - there could be many. That is what this new API function offers, it returns a list (possibly empty) of all global static symbols matching a given name (and optionally a given symbol domain). gdb/ChangeLog: * python/py-symbol.c (gdbpy_lookup_static_symbols): New function. * python/python-internal.h (gdbpy_lookup_static_symbols): Declare new function. * python/python.c (python_GdbMethods): Add gdb.lookup_static_symbols method. * NEWS: Mention gdb.lookup_static_symbols. gdb/testsuite/ChangeLog: * gdb.python/py-symbol.exp: Add test for gdb.lookup_static_symbols. gdb/doc/ChangeLog: * python.texi (Symbols In Python): Add documentation for gdb.lookup_static_symbols. Change-Id: I1153b0ae5bcbc43b3dcf139043c7a48bf791e1a3
2019-07-30[PR/24474] Add gdb.lookup_static_symbol to the python APIChristian Biesinger1-0/+2
Similar to lookup_global_symbol, except that it checks the STATIC_SCOPE. gdb/ChangeLog: 2019-07-30 Christian Biesinger <cbiesinger@google.com> PR/24474: Add a function to lookup static variables. * NEWS: Mention this new function. * python/py-symbol.c (gdbpy_lookup_static_symbol): New function. * python/python-internal.h (gdbpy_lookup_static_symbol): New function. * python/python.c (python_GdbMethods): Add new function. gdb/doc/ChangeLog: 2019-07-30 Christian Biesinger <cbiesinger@google.com> * python.texi (Symbols In Python): Document new function gdb.lookup_static_symbol. gdb/testsuite/ChangeLog: 2019-07-30 Christian Biesinger <cbiesinger@google.com> * gdb.python/py-symbol.c: Add a static variable and one in an anonymous namespace. * gdb.python/py-symbol.exp: Test gdb.lookup_static_symbol.
2019-07-10Reduce manual reference counting in py-inferior.cTom Tromey1-1/+1
This patch changes py-inferior.c to use gdbpy_ref<> when possible, reducing the amount of manual reference counting. Tested on x86-64 Fedora 29. gdb/ChangeLog 2019-07-10 Tom Tromey <tromey@adacore.com> * python/python-internal.h (create_thread_object): Return gdbpy_ref. * python/py-infthread.c (create_thread_object): Return gdbpy_ref. * python/py-inferior.c (struct threadlist_entry): Add constructor. <thread_obj>: Now a gdbpy_ref. (thread_to_thread_object): Update. (add_thread_object): Use new. (delete_thread_object): Use delete. (infpy_threads): Update. (py_free_inferior): Update. Construct "inf_obj" after acquiring GIL.
2019-04-25Make exception handling more efficientTom Tromey1-1/+1
This makes exception handling more efficient in a few spots, through the use of const- and rvalue-references. I wrote this patch by commenting out the gdb_exception copy constructor and then examining the resulting error messages one by one, introducing the use of std::move where appropriate. gdb/ChangeLog 2019-04-25 Tom Tromey <tromey@adacore.com> * xml-support.c (struct gdb_xml_parser) <set_error>: Take an rvalue reference. (gdb_xml_start_element_wrapper, gdb_xml_end_element_wrapper) (gdb_xml_parser::parse): Use std::move. * python/python-internal.h (gdbpy_convert_exception): Take a const reference. * python/py-value.c (valpy_getitem, valpy_nonzero): Use std::move. * python/py-utils.c (gdbpy_convert_exception): Take a const reference. * python/py-inferior.c (infpy_write_memory, infpy_search_memory): Use std::move. * python/py-breakpoint.c (bppy_set_condition, bppy_set_commands): Use std::move. * mi/mi-main.c (mi_print_exception): Take a const reference. * main.c (handle_command_errors): Take a const reference. * linespec.c (parse_linespec): Use std::move. * infcall.c (run_inferior_call): Use std::move. (call_function_by_hand_dummy): Use std::move. * exec.c (try_open_exec_file): Use std::move. * exceptions.h (exception_print, exception_fprintf) (exception_print_same): Update. * exceptions.c (print_exception, exception_print) (exception_fprintf, exception_print_same): Change parameters to const reference. * event-top.c (gdb_rl_callback_read_char_wrapper): Update. * common/new-op.c: Use std::move. * common/common-exceptions.h (struct gdb_exception): Add move constructor. (struct gdb_exception_error, struct gdb_exception_quit, struct gdb_quit_bad_alloc): Change constructor to move constructor. (throw_exception): Change parameter to rvalue reference. * common/common-exceptions.c (throw_exception): Take rvalue reference. * cli/cli-interp.c (safe_execute_command): Use std::move. * breakpoint.c (insert_bp_location, location_to_sals): Use std::move.
2019-02-27Remove Python 2.4 and 2.5 supportTom Tromey1-52/+1
This removes all the remainings spots I could find that work around issues in Python 2.4 and 2.5. I don't have a good way to test that Python 2.6 still works. Tested by the buildbot. gdb/ChangeLog 2019-02-27 Tom Tromey <tromey@adacore.com> * config.in, configure: Rebuild. * configure.ac (HAVE_LIBPYTHON2_4, HAVE_LIBPYTHON2_5): Never define. * python/py-value.c: Remove Python 2.4 workaround. * python/py-utils.c (gdb_pymodule_addobject): Remove Python 2.4 workaround. * python/py-type.c (convert_field, gdbpy_initialize_types): Remove Python 2.4 workaround. * python/python-internal.h: Remove Python 2.4 comment. (Py_ssize_t): Don't define. (PyVarObject_HEAD_INIT, Py_TYPE): Don't define. (gdb_Py_DECREF): Remove Python 2.4 workaround. (gdb_PyObject_GetAttrString, PyObject_GetAttrString): Remove. (gdb_PyObject_HasAttrString, PyObject_HasAttrString): Remove. * python/python.c (do_start_initialization): Remove Python 2.4 workaround. * python/py-prettyprint.c (class dummy_python_frame): Remove. (print_children): Remove Python 2.4 workaround. * python/py-inferior.c (buffer_procs): Remove Python 2.4 workaround. (CHARBUFFERPROC_NAME): Remove. * python/py-breakpoint.c (gdbpy_initialize_breakpoints): Remove Python 2.4 workaround. gdb/testsuite/ChangeLog 2019-02-27 Tom Tromey <tromey@adacore.com> * lib/gdb.exp (skip_python_tests_prompt): Don't check for Python 2.4. * gdb.python/py-finish-breakpoint.exp: Remove Python 2.4 workaround. gdb/ChangeLog 2019-02-27 Tom Tromey <tromey@adacore.com> * config.in, configure: Rebuild. * configure.ac (HAVE_LIBPYTHON2_4, HAVE_LIBPYTHON2_5): Never define. * python/py-value.c: Remove Python 2.4 workaround. * python/py-utils.c (gdb_pymodule_addobject): Remove Python 2.4 workaround. * python/py-type.c (convert_field, gdbpy_initialize_types): Remove Python 2.4 workaround. * python/python-internal.h: Remove Python 2.4 comment. (Py_ssize_t): Don't define. (PyVarObject_HEAD_INIT, Py_TYPE): Don't define. (gdb_Py_DECREF): Remove Python 2.4 workaround. (gdb_PyObject_GetAttrString, PyObject_GetAttrString): Remove. (gdb_PyObject_HasAttrString, PyObject_HasAttrString): Remove. * python/python.c (do_start_initialization): Remove Python 2.4 workaround. * python/py-prettyprint.c (class dummy_python_frame): Remove. (print_children): Remove Python 2.4 workaround. * python/py-inferior.c (buffer_procs): Remove Python 2.4 workaround. (CHARBUFFERPROC_NAME): Remove. * python/py-breakpoint.c (gdbpy_initialize_breakpoints): Remove Python 2.4 workaround.
2019-02-26Define unique_ptr specialization for Py_buffer.Kevin Buettner1-0/+13
This patch causes PyBuffer_Release() to be called when the associated buffer goes out of scope. I've been using it as follows: ... Py_buffer_up buffer_up; Py_buffer py_buf; if (PyObject_CheckBuffer (obj) && PyObject_GetBuffer (obj, &py_buf, PyBUF_SIMPLE) == 0) { /* Got a buffer, py_buf, out of obj. Cause it to released when it goes out of scope. */ buffer_up.reset (&py_buf); } ... This snippet of code was taken directly from an upcoming patch to python-value.c. gdb/ChangeLog: * python/python-internal.h (Py_buffer_deleter): New struct. (Py_buffer_up): New typedef.
2019-02-07Normalize include guards in gdbTom Tromey1-3/+3
While working on my other scripts to deal with gdb headers, I noticed that some files were missing include guards. I wrote a script to add the missing ones, but found that using the obvious names for the guards ran into clashes -- for example, gdb/nat/linux-nat.h used "LINUX_NAT_H", but this was also the script's choice for gdb/linux-nat.h. So, I changed the script to normalize all include guards in gdb. This patch is the result. As usual the script is available here: https://github.com/tromey/gdb-refactoring-scripts Tested by rebuilding; I also ran it through "Fedora-x86_64-m64" on the buildbot. gdb/ChangeLog 2019-02-07 Tom Tromey <tom@tromey.com> * yy-remap.h: Add include guard. * xtensa-tdep.h: Add include guard. * xcoffread.h: Rename include guard. * varobj-iter.h: Add include guard. * tui/tui.h: Rename include guard. * tui/tui-winsource.h: Rename include guard. * tui/tui-wingeneral.h: Rename include guard. * tui/tui-windata.h: Rename include guard. * tui/tui-win.h: Rename include guard. * tui/tui-stack.h: Rename include guard. * tui/tui-source.h: Rename include guard. * tui/tui-regs.h: Rename include guard. * tui/tui-out.h: Rename include guard. * tui/tui-layout.h: Rename include guard. * tui/tui-io.h: Rename include guard. * tui/tui-hooks.h: Rename include guard. * tui/tui-file.h: Rename include guard. * tui/tui-disasm.h: Rename include guard. * tui/tui-data.h: Rename include guard. * tui/tui-command.h: Rename include guard. * tic6x-tdep.h: Add include guard. * target/waitstatus.h: Rename include guard. * target/wait.h: Rename include guard. * target/target.h: Rename include guard. * target/resume.h: Rename include guard. * target-float.h: Rename include guard. * stabsread.h: Add include guard. * rs6000-tdep.h: Add include guard. * riscv-fbsd-tdep.h: Add include guard. * regformats/regdef.h: Rename include guard. * record.h: Rename include guard. * python/python.h: Rename include guard. * python/python-internal.h: Rename include guard. * python/py-stopevent.h: Rename include guard. * python/py-ref.h: Rename include guard. * python/py-record.h: Rename include guard. * python/py-record-full.h: Rename include guard. * python/py-record-btrace.h: Rename include guard. * python/py-instruction.h: Rename include guard. * python/py-events.h: Rename include guard. * python/py-event.h: Rename include guard. * procfs.h: Add include guard. * proc-utils.h: Add include guard. * p-lang.h: Add include guard. * or1k-tdep.h: Rename include guard. * observable.h: Rename include guard. * nto-tdep.h: Rename include guard. * nat/x86-linux.h: Rename include guard. * nat/x86-linux-dregs.h: Rename include guard. * nat/x86-gcc-cpuid.h: Add include guard. * nat/x86-dregs.h: Rename include guard. * nat/x86-cpuid.h: Rename include guard. * nat/ppc-linux.h: Rename include guard. * nat/mips-linux-watch.h: Rename include guard. * nat/linux-waitpid.h: Rename include guard. * nat/linux-ptrace.h: Rename include guard. * nat/linux-procfs.h: Rename include guard. * nat/linux-osdata.h: Rename include guard. * nat/linux-nat.h: Rename include guard. * nat/linux-namespaces.h: Rename include guard. * nat/linux-btrace.h: Rename include guard. * nat/glibc_thread_db.h: Rename include guard. * nat/gdb_thread_db.h: Rename include guard. * nat/gdb_ptrace.h: Rename include guard. * nat/fork-inferior.h: Rename include guard. * nat/amd64-linux-siginfo.h: Rename include guard. * nat/aarch64-sve-linux-sigcontext.h: Rename include guard. * nat/aarch64-sve-linux-ptrace.h: Rename include guard. * nat/aarch64-linux.h: Rename include guard. * nat/aarch64-linux-hw-point.h: Rename include guard. * mn10300-tdep.h: Add include guard. * mips-linux-tdep.h: Add include guard. * mi/mi-parse.h: Rename include guard. * mi/mi-out.h: Rename include guard. * mi/mi-main.h: Rename include guard. * mi/mi-interp.h: Rename include guard. * mi/mi-getopt.h: Rename include guard. * mi/mi-console.h: Rename include guard. * mi/mi-common.h: Rename include guard. * mi/mi-cmds.h: Rename include guard. * mi/mi-cmd-break.h: Rename include guard. * m2-lang.h: Add include guard. * location.h: Rename include guard. * linux-record.h: Rename include guard. * linux-nat.h: Add include guard. * linux-fork.h: Add include guard. * i386-darwin-tdep.h: Rename include guard. * hppa-linux-offsets.h: Add include guard. * guile/guile.h: Rename include guard. * guile/guile-internal.h: Rename include guard. * gnu-nat.h: Rename include guard. * gdb-stabs.h: Rename include guard. * frv-tdep.h: Add include guard. * f-lang.h: Add include guard. * event-loop.h: Add include guard. * darwin-nat.h: Rename include guard. * cp-abi.h: Rename include guard. * config/sparc/nm-sol2.h: Rename include guard. * config/nm-nto.h: Rename include guard. * config/nm-linux.h: Add include guard. * config/i386/nm-i386gnu.h: Rename include guard. * config/djgpp/nl_types.h: Rename include guard. * config/djgpp/langinfo.h: Rename include guard. * compile/gcc-cp-plugin.h: Add include guard. * compile/gcc-c-plugin.h: Add include guard. * compile/compile.h: Rename include guard. * compile/compile-object-run.h: Rename include guard. * compile/compile-object-load.h: Rename include guard. * compile/compile-internal.h: Rename include guard. * compile/compile-cplus.h: Rename include guard. * compile/compile-c.h: Rename include guard. * common/xml-utils.h: Rename include guard. * common/x86-xstate.h: Rename include guard. * common/version.h: Rename include guard. * common/vec.h: Rename include guard. * common/tdesc.h: Rename include guard. * common/selftest.h: Rename include guard. * common/scoped_restore.h: Rename include guard. * common/scoped_mmap.h: Rename include guard. * common/scoped_fd.h: Rename include guard. * common/safe-iterator.h: Rename include guard. * common/run-time-clock.h: Rename include guard. * common/refcounted-object.h: Rename include guard. * common/queue.h: Rename include guard. * common/ptid.h: Rename include guard. * common/print-utils.h: Rename include guard. * common/preprocessor.h: Rename include guard. * common/pathstuff.h: Rename include guard. * common/observable.h: Rename include guard. * common/netstuff.h: Rename include guard. * common/job-control.h: Rename include guard. * common/host-defs.h: Rename include guard. * common/gdb_wait.h: Rename include guard. * common/gdb_vecs.h: Rename include guard. * common/gdb_unlinker.h: Rename include guard. * common/gdb_unique_ptr.h: Rename include guard. * common/gdb_tilde_expand.h: Rename include guard. * common/gdb_sys_time.h: Rename include guard. * common/gdb_string_view.h: Rename include guard. * common/gdb_splay_tree.h: Rename include guard. * common/gdb_setjmp.h: Rename include guard. * common/gdb_ref_ptr.h: Rename include guard. * common/gdb_optional.h: Rename include guard. * common/gdb_locale.h: Rename include guard. * common/gdb_assert.h: Rename include guard. * common/filtered-iterator.h: Rename include guard. * common/filestuff.h: Rename include guard. * common/fileio.h: Rename include guard. * common/environ.h: Rename include guard. * common/common-utils.h: Rename include guard. * common/common-types.h: Rename include guard. * common/common-regcache.h: Rename include guard. * common/common-inferior.h: Rename include guard. * common/common-gdbthread.h: Rename include guard. * common/common-exceptions.h: Rename include guard. * common/common-defs.h: Rename include guard. * common/common-debug.h: Rename include guard. * common/cleanups.h: Rename include guard. * common/buffer.h: Rename include guard. * common/btrace-common.h: Rename include guard. * common/break-common.h: Rename include guard. * cli/cli-utils.h: Rename include guard. * cli/cli-style.h: Rename include guard. * cli/cli-setshow.h: Rename include guard. * cli/cli-script.h: Rename include guard. * cli/cli-interp.h: Rename include guard. * cli/cli-decode.h: Rename include guard. * cli/cli-cmds.h: Rename include guard. * charset-list.h: Add include guard. * buildsym-legacy.h: Rename include guard. * bfin-tdep.h: Add include guard. * ax.h: Rename include guard. * arm-linux-tdep.h: Add include guard. * arm-fbsd-tdep.h: Add include guard. * arch/xtensa.h: Rename include guard. * arch/tic6x.h: Add include guard. * arch/i386.h: Add include guard. * arch/arm.h: Rename include guard. * arch/arm-linux.h: Rename include guard. * arch/arm-get-next-pcs.h: Rename include guard. * arch/amd64.h: Add include guard. * arch/aarch64-insn.h: Rename include guard. * arch-utils.h: Rename include guard. * annotate.h: Add include guard. * amd64-darwin-tdep.h: Rename include guard. * aarch64-linux-tdep.h: Add include guard. * aarch64-fbsd-tdep.h: Add include guard. * aarch32-linux-nat.h: Add include guard. gdb/gdbserver/ChangeLog 2019-02-07 Tom Tromey <tom@tromey.com> * x86-tdesc.h: Rename include guard. * x86-low.h: Add include guard. * wincecompat.h: Rename include guard. * win32-low.h: Add include guard. * utils.h: Rename include guard. * tracepoint.h: Rename include guard. * tdesc.h: Rename include guard. * target.h: Rename include guard. * server.h: Rename include guard. * remote-utils.h: Rename include guard. * regcache.h: Rename include guard. * nto-low.h: Rename include guard. * notif.h: Add include guard. * mem-break.h: Rename include guard. * lynx-low.h: Add include guard. * linux-x86-tdesc.h: Add include guard. * linux-s390-tdesc.h: Add include guard. * linux-ppc-tdesc-init.h: Add include guard. * linux-low.h: Add include guard. * linux-aarch64-tdesc.h: Add include guard. * linux-aarch32-low.h: Add include guard. * inferiors.h: Rename include guard. * i387-fp.h: Rename include guard. * hostio.h: Rename include guard. * gdbthread.h: Rename include guard. * gdb_proc_service.h: Rename include guard. * event-loop.h: Rename include guard. * dll.h: Rename include guard. * debug.h: Rename include guard. * ax.h: Rename include guard.
2019-01-30Release the GIL while running a gdb command or expressionTom Tromey1-0/+25
PR python/23615 points out that gdb.execute_gdb_command does not release the Python GIL. This means that, while the gdb command is running, other Python threads do not run. This patch solves the problem by introducing a new RAII class that can be used to temporarily release and then re-acquire the GIL, then puts this into the appropriate places in execute_gdb_command and gdbpy_parse_and_eval. This does not include a test case, because after some research I could not find a way to write one that was not racy. gdb/ChangeLog 2019-01-30 Tom Tromey <tom@tromey.com> PR python/23615: * python/python.c (execute_gdb_command): Use gdbpy_allow_threads. (gdbpy_parse_and_eval): Likewise. * python/python-internal.h (gdbpy_allow_threads): New class.
2019-01-03Use a wrapper for PyErr_FetchTom Tromey1-3/+58
This introduces a new class that wraps PyErr_Fetch and PyErr_Restore, and then changes all the callers in gdb to use it. This reduces the amount of explicit reference counting that is done in the Python code. I also found and fixed a latent bug in gdbpy_print_stack -- it was not correctly checking some error conditions, nor clearing the exception when needed. gdb/ChangeLog 2019-01-03 Tom Tromey <tom@tromey.com> * python/python.c (gdbpy_enter, ~gdbpy_enter): Update. (gdbpy_print_stack): Use gdbpy_err_fetch. * python/python-internal.h (class gdbpy_err_fetch): New class. (class gdbpy_enter) <m_error_type, m_error_value, m_error_traceback>: Remove. <m_error>: New member. (gdbpy_exception_to_string): Don't declare. * python/py-varobj.c (py_varobj_iter_next): Use gdbpy_err_fetch. * python/py-value.c (convert_value_from_python): Use gdbpy_err_fetch. * python/py-utils.c (gdbpy_err_fetch::to_string): Rename from gdbpy_exception_to_string. (gdbpy_handle_exception): Use gdbpy_err_fetch. * python/py-prettyprint.c (print_stack_unless_memory_error): Use gdbpy_err_fetch.