aboutsummaryrefslogtreecommitdiff
path: root/gdb/doc/python.texi
AgeCommit message (Collapse)AuthorFilesLines
2021-06-21gdb/python: add PendingFrame.level and Frame.level methodsAndrew Burgess1-0/+9
Add new methods to the PendingFrame and Frame classes to obtain the stack frame level for each object. The use of 'level' as the method name is consistent with the existing attribute RecordFunctionSegment.level (though this is an attribute rather than a method). For Frame/PendingFrame I went with methods as these classes currently only use methods, including for simple data like architecture, so I want to be consistent with this interface. gdb/ChangeLog: * NEWS: Mention the two new methods. * python/py-frame.c (frapy_level): New function. (frame_object_methods): Register 'level' method. * python/py-unwind.c (pending_framepy_level): New function. (pending_frame_object_methods): Register 'level' method. gdb/doc/ChangeLog: * python.texi (Unwinding Frames in Python): Mention PendingFrame.level. (Frames In Python): Mention Frame.level. gdb/testsuite/ChangeLog: * gdb.python/py-frame.exp: Add Frame.level tests. * gdb.python/py-pending-frame-level.c: New file. * gdb.python/py-pending-frame-level.exp: New file. * gdb.python/py-pending-frame-level.py: New file.
2021-06-08Use is/is not to check for None in python code.Lancelot SIX1-1/+1
While reviewing a patch sent to the mailing list, I noticed there are few places where python code checks if a variable is 'None' or not by using the comparison operators '==' and '!='. PEP8[1], which is used as coding standard in GDB coding standards, recommends using 'is' / 'is not' when comparing to a singleton such as 'None'. This patch proposes to change the instances of '== None' by 'is None' and '!= None' by 'is not None'. [1] https://www.python.org/dev/peps/pep-0008/ gdb/doc/ChangeLog: * python.texi (Writing a Pretty-Printer): Use 'is None' instead of '== None'. gdb/ChangeLog: * python/lib/gdb/FrameDecorator.py (FrameDecorator): Use 'is None' instead of '== None'. (FrameVars): Use 'is not None' instead of '!= None'. * python/lib/gdb/command/frame_filters.py (SetFrameFilterPriority): Use 'is None' instead of '== None' and 'is not None' instead of '!= None'. gdb/testsuite/ChangeLog: * gdb.base/premature-dummy-frame-removal.py (TestUnwinder): Use 'is None' instead of '== None' and 'is not None' instead of '!= None'. * gdb.python/py-frame-args.py (lookup_function): Same. * gdb.python/py-framefilter-invalidarg.py (Reverse_Function): Same. * gdb.python/py-framefilter.py (Reverse_Function): Same. * gdb.python/py-nested-maps.py (lookup_function): Same. * gdb.python/py-objfile-script-gdb.py (lookup_function): Same. * gdb.python/py-prettyprint.py (lookup_function): Same. * gdb.python/py-section-script.py (lookup_function): Same. * gdb.python/py-unwind-inline.py (dummy_unwinder): Same. * gdb.python/python.exp: Same. * gdb.rust/pp.py (lookup_function): Same.
2021-06-04Forward mouse click to python TUI windowHannes Domani1-0/+7
If the TUI window object implements the click method, it is called for each mouse click event in this window. gdb/ChangeLog: 2021-06-04 Hannes Domani <ssbssa@yahoo.de> * python/py-tui.c (class tui_py_window): Add click function. (tui_py_window::click): Likewise. gdb/doc/ChangeLog: 2021-06-04 Hannes Domani <ssbssa@yahoo.de> * python.texi (TUI Windows In Python): Document Window.click.
2021-05-29Fix InlinedFrameDecorator exampleHannes Domani1-1/+1
Argument fobj was only available in the constructor. gdb/doc/ChangeLog: 2021-05-29 Hannes Domani <ssbssa@yahoo.de> * python.texi (Writing a Frame Filter): Fix example.
2021-05-27Add optional full_window argument to TuiWindow.writeHannes Domani1-1/+5
To prevent flickering when first calling erase, then write, this new argument indicates that the passed string contains the full contents of the window. This fills every unused cell of the window with a space, so it's not necessary to call erase beforehand. gdb/ChangeLog: 2021-05-27 Hannes Domani <ssbssa@yahoo.de> * python/py-tui.c (tui_py_window::output): Add full_window argument. (gdbpy_tui_write): Parse "full_window" argument. gdb/doc/ChangeLog: 2021-05-27 Hannes Domani <ssbssa@yahoo.de> * python.texi (TUI Windows In Python): Document "full_window" argument.
2021-05-27Document gdb.SYMBOL_LOC_LABELHannes Domani1-0/+4
Looks like it was missing from the beginning. gdb/doc/ChangeLog: 2021-05-27 Hannes Domani <ssbssa@yahoo.de> * python.texi (Symbols In Python): Document gdb.SYMBOL_LOC_LABEL.
2021-05-25Fix documentation of gdb.SYMBOL_LOC_COMMON_BLOCKHannes Domani1-2/+2
gdb/doc/ChangeLog: 2021-05-25 Hannes Domani <ssbssa@yahoo.de> * python.texi (Symbols In Python): Fix gdb.SYMBOL_LOC_COMMON_BLOCK.
2021-05-14gdb/python: add a 'connection_num' attribute to Inferior objectsTankut Baris Aktemur1-0/+6
Define a 'connection_num' attribute for Inferior objects. The read-only attribute is the ID of the connection of an inferior, as printed by "info inferiors". In GDB's internal terminology, that's the process stratum target of the inferior. If the inferior has no target connection, the attribute is None. gdb/ChangeLog: 2021-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * python/py-inferior.c (infpy_get_connection_num): New function. (inferior_object_getset): Add a new element for 'connection_num'. * NEWS: Mention the 'connection_num' attribute of Inferior objects. gdb/doc/ChangeLog: 2021-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * python.texi (Inferiors In Python): Mention the 'connection_num' attribute. gdb/testsuite/ChangeLog: 2021-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.python/py-inferior.exp: Add test cases for 'connection_num'.
2021-05-10gdb/doc: reword a sentenceAndrew Burgess1-1/+1
Change this: The available watchpoint types represented by constants are defined in the gdb module: to this: The available watchpoint types are represented by constants defined in the gdb module: The new version matches a similar line a few lines up the document which reads: The available types are represented by constants defined in the gdb module: gdb/doc/ChangeLog: * guile.texinfo (Breakpoints In Guile): Reword sentence. * python.texinfo (Breakpoints In Python): Reword sentence.
2021-05-09gdb/doc: document 'set debug py-unwind'Andrew Burgess1-0/+7
When the 'set debug py-unwind' flag was added, it was never documented in the manual. This commit adds some text for this command to the manual. gdb/doc/ChangeLog: * python.texinfo (Python Commands): Document 'set debug py-unwind' and 'show debug py-unwind'.
2021-05-09gdb/py: add some debugging to py-breakpoint.cAndrew Burgess1-0/+11
Adds some new debugging to python/py-breakpoint.c. gdb/ChangeLog: * python/py-breakpoint.c (pybp_debug): New static global. (show_pybp_debug): New function. (pybp_debug_printf): Define. (PYBP_SCOPED_DEBUG_ENTER_EXIT): Define. (gdbpy_breakpoint_created): Add some debugging. (gdbpy_breakpoint_deleted): Likewise. (gdbpy_breakpoint_modified): Likewise. (_initialize_py_breakpoint): New function. gdb/doc/ChangeLog: * python.texinfo (Python Commands): Document 'set debug py-breakpoint' and 'show debug py-breakpoint'.
2021-05-04gdb: update Type.fields doc based on actual GDB behaviorSimon Marchi1-6/+26
I noticed two errors in the Type.fields documentation: 1. It is possible to call `fields` on an array type, in which case it returns one field representing the array's range. It is not mentioned. 2. When calling `fields` on a type that doesn't have fields (by nature, like an int), GDB raises a TypeError. It does not return an empty sequence, as currently documented. Fix these, and change the text into a bullet list. I find it easier to read than one big paragraph. The first issue is already tested in gdb.python/py-type.exp, but the second one doesn't seem tested. Add a test in gdb.python/py-type.exp for it. gdb/doc/ChangeLog: * python.texi (Types In Python): Re-organize Type.fields doc. Mention handling of array types. Correct doc for when calling the method on another type. gdb/testsuite/ChangeLog: * gdb.python/py-type.exp (test_fields): Test calling fields on an int type. Change-Id: I11c688177504cb070b81a4446ac91dec50b56a22
2021-04-28gdb: startup commands to control Python extension languageAndrew Burgess1-0/+38
Add two new commands to GDB that can be placed into the early initialization to control how Python starts up. The new options are: set python ignore-environment on|off set python dont-write-bytecode auto|on|off show python ignore-environment show python dont-write-bytecode These can be used from GDB's startup file to control how the Python extension language behaves. These options are equivalent to the -E and -B flags to python respectively, their descriptions from the Python man page: -E Ignore environment variables like PYTHONPATH and PYTHONHOME that modify the behavior of the interpreter. -B Don't write .pyc files on import. gdb/ChangeLog: * NEWS: Mention new commands. * python/python.c (python_ignore_environment): New static global. (show_python_ignore_environment): New function. (set_python_ignore_environment): New function. (python_dont_write_bytecode): New static global. (show_python_dont_write_bytecode): New function. (set_python_dont_write_bytecode): New function. (_initialize_python): Register new commands. gdb/doc/ChangeLog: * python.texinfo (Python Commands): Mention new commands. gdb/testsuite/ChangeLog: * gdb.python/py-startup-opt.exp: New file.
2021-03-18gdb/doc: fix the example for get_set_string in Python API docsAndrew Burgess1-0/+1
The small example for gdb.Parameter.get_set_string does not return a string. The documentation is very clear that this method must return a string, and indeed, inspecting the code in gdb/python/py-param.c shows that a string return value is required (if an exception is not thrown). While inspecting the code in gdb/python/py-param.c I noticed that the comment for the C++ code that invokes the Python get_set_string method is wrong, so I updated that too. gdb/ChangeLog: * python/py-param.c (get_set_value): Update header comment. gdb/doc/ChangeLog: * python.texinfo (Parameters In Python): Return empty string in small example code.
2021-02-08gdb: return true in TuiWindow.is_valid only if TUI is enabledAndrew Burgess1-0/+5
If the user implements a TUI window in Python, and this window responds to GDB events and then redraws its window contents then there is currently an edge case which can lead to problems. The Python API documentation suggests that calling methods like erase or write on a TUI window (from Python code) will raise an exception if the window is not valid. And the description for is_valid says: This method returns True when this window is valid. When the user changes the TUI layout, windows no longer visible in the new layout will be destroyed. At this point, the gdb.TuiWindow will no longer be valid, and methods (and attributes) other than is_valid will throw an exception. From this I, as a user, would expect that if I did 'tui disable' to switch back to CLI mode, then the window would no longer be valid. However, this is not the case. When the TUI is disabled the windows in the TUI are not deleted, they are simply hidden. As such, currently, the is_valid method continues to return true. This means that if the users Python code does something like: def event_handler (e): global tui_window_object if tui_window_object->is_valid (): tui_window_object->erase () tui_window_object->write ("Hello World") gdb.events.stop.connect (event_handler) Then when a stop event arrives GDB will try to draw the TUI window, even when the TUI is disabled. This exposes two bugs. First, is_valid should be returning false in this case, second, if the user forgot to add the is_valid call, then I believe the erase and write calls should be throwing an exception (when the TUI is disabled). The solution to both of these issues is I think bound together, as it depends on having a working 'is_valid' check. There's a rogue assert added into tui-layout.c as part of this commit. While working on this commit I managed to break GDB such that TUI_CMD_WIN was nullptr, this was causing GDB to abort. I'm leaving the assert in as it might help people catch issues in the future. This patch is inspired by the work done here: https://sourceware.org/pipermail/gdb-patches/2020-December/174338.html gdb/ChangeLog: * python/py-tui.c (gdbpy_tui_window) <is_valid>: New member function. (REQUIRE_WINDOW): Call is_valid member function. (REQUIRE_WINDOW_FOR_SETTER): New define. (gdbpy_tui_is_valid): Call is_valid member function. (gdbpy_tui_set_title): Call REQUIRE_WINDOW_FOR_SETTER instead. * tui/tui-data.h (struct tui_win_info) <is_visible>: Check tui_active too. * tui/tui-layout.c (tui_apply_current_layout): Add an assert. * tui/tui.c (tui_enable): Move setting of tui_active earlier in the function. gdb/doc/ChangeLog: * python.texinfo (TUI Windows In Python): Extend description of TuiWindow.is_valid. gdb/testsuite/ChangeLog: * gdb.python/tui-window-disabled.c: New file. * gdb.python/tui-window-disabled.exp: New file. * gdb.python/tui-window-disabled.py: New file.
2021-01-25gdb/docs: add parentheses in Python examples using printMarco Barisione1-9/+9
This makes the examples work both in Python 2 and 3. gdb/doc/ChangeLog: * python.texi: Add parentheses to print statements/functions. Change-Id: I8571f2ee005acd96c7bb43f9882d19b00b2aa3db
2021-01-21Add Python support for hardware breakpointsHannes Domani1-0/+4
This allows the creation of hardware breakpoints in Python with gdb.Breakpoint(type=gdb.BP_HARDWARE_BREAKPOINT) And they are included in the sequence returned by gdb.breakpoints(). gdb/ChangeLog: 2021-01-21 Hannes Domani <ssbssa@yahoo.de> PR python/19151 * python/py-breakpoint.c (bppy_get_location): Handle bp_hardware_breakpoint. (bppy_init): Likewise. (gdbpy_breakpoint_created): Likewise. gdb/doc/ChangeLog: 2021-01-21 Hannes Domani <ssbssa@yahoo.de> PR python/19151 * python.texi (Breakpoints In Python): Document gdb.BP_HARDWARE_BREAKPOINT. gdb/testsuite/ChangeLog: 2021-01-21 Hannes Domani <ssbssa@yahoo.de> PR python/19151 * gdb.python/py-breakpoint.exp: Add tests for hardware breakpoints.
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-29Fix wrong method nameHannes Domani1-1/+1
The objects returned by FrameDecorator.frame_args need to implement a method named symbol, not argument. gdb/doc/ChangeLog: 2020-12-29 Hannes Domani <ssbssa@yahoo.de> * python.texi (Frame Decorator API): Fix method name.
2020-12-18Remove erroneous 'a' in gdb.register_window_type documentationHannes Domani1-1/+1
gdb/doc/ChangeLog: 2020-12-18 Hannes Domani <ssbssa@yahoo.de> * python.texi (TUI Windows In Python): Remove erroneous 'a'.
2020-12-18Add address keyword to Value.format_stringHannes Domani1-0/+5
This makes it possible to disable the address in the result string: const char *str = "alpha"; (gdb) py print(gdb.parse_and_eval("str").format_string()) 0x404000 "alpha" (gdb) py print(gdb.parse_and_eval("str").format_string(address=False)) "alpha" gdb/ChangeLog: 2020-12-18 Hannes Domani <ssbssa@yahoo.de> * python/py-value.c (valpy_format_string): Implement address keyword. gdb/doc/ChangeLog: 2020-12-18 Hannes Domani <ssbssa@yahoo.de> * python.texi (Values From Inferior): Document the address keyword. gdb/testsuite/ChangeLog: 2020-12-18 Hannes Domani <ssbssa@yahoo.de> * gdb.python/py-format-string.exp: Add tests for address keyword.
2020-11-29Fix Value.format_string docu for static members argumentHannes Domani1-1/+1
The argument is called static_members, not static_fields. gdb/doc/ChangeLog: 2020-11-29 Hannes Domani <ssbssa@yahoo.de> PR python/26974 * python.texi: Fix docu for static members argument.
2020-07-28gdb/python: make more use of RegisterDescriptorsAndrew Burgess1-12/+30
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-28gdb: Add a find method for RegisterDescriptorIteratorAndrew Burgess1-0/+9
Adds a new method 'find' to the gdb.RegisterDescriptorIterator class, this allows gdb.RegisterDescriptor objects to be looked up directly by register name rather than having to iterate over all registers. This will be of use for a later commit. I've documented the new function in the manual, but I don't think a NEWS entry is required here, as, since the last release, the whole register descriptor mechanism is new, and is already mentioned in the NEWS file. gdb/ChangeLog: * python/py-registers.c: Add 'user-regs.h' include. (register_descriptor_iter_find): New function. (register_descriptor_iterator_object_methods): New static global methods array. (register_descriptor_iterator_object_type): Add pointer to methods array. gdb/testsuite/ChangeLog: * gdb.python/py-arch-reg-names.exp: Add additional tests. gdb/doc/ChangeLog: * python.texi (Registers In Python): Document new find function.
2020-07-06gdb/python: New method to access list of register groupsAndrew Burgess1-0/+32
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/+33
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-07-06gdb/python: Add architecture method to gdb.PendingFrameAndrew Burgess1-0/+6
It could be useful to determine the architecture of a frame being unwound during the frame unwind process, that is, before we have a gdb.Frame, but when we only have a gdb.PendingFrame. The PendingFrame already has a pointer to the gdbarch internally, this commit just exposes an 'architecture' method to Python, and has this return a gdb.Architecture object (list gdb.Frame.architecture does). gdb/ChangeLog: * NEWS: Mention new Python API method. * python/py-unwind.c (pending_framepy_architecture): New function. (pending_frame_object_methods): Add architecture method. gdb/testsuite/ChangeLog: * gdb.python/py-unwind.py (TestUnwinder::__call__): Add test for gdb.PendingFrame.architecture method. gdb/doc/ChangeLog: * python.texi (Unwinding Frames in Python): Document PendingFrame.architecture method.
2020-04-28Allow Python commands to be in class_tuiTom Tromey1-0/+7
Now that Python code can create TUI windows, it seemed appropriate to allow Python commands to appear in the "TUI" help class. This patch adds this capability. gdb/ChangeLog 2020-04-28 Tom Tromey <tom@tromey.com> * NEWS: Update. * python/py-cmd.c (gdbpy_initialize_commands): Add COMMAND_TUI. (cmdpy_init): Allow class_tui. gdb/doc/ChangeLog 2020-04-28 Tom Tromey <tom@tromey.com> * python.texi (Commands In Python): Document gdb.COMMAND_TUI.
2020-04-27Expand dynamic type documentationTom Tromey1-2/+20
This expands the Python dynamic type documentation, as suggested by Christian. gdb/doc/ChangeLog 2020-04-27 Tom Tromey <tromey@adacore.com> * python.texi (Types In Python): Mention missing fields. Add dynamic type example.
2020-04-24Add Python support for dynamic typesTom Tromey1-2/+12
This changes the gdb Python API to add support for dynamic types. In particular, this adds an attribute to gdb.Type, and updates some attributes to reflect dynamic sizes and field offsets. There's still no way to get the dynamic type from one of its concrete instances. This could perhaps be added if needed. gdb/ChangeLog 2020-04-24 Tom Tromey <tromey@adacore.com> PR python/23662: * python/py-type.c (convert_field): Handle FIELD_LOC_KIND_DWARF_BLOCK. (typy_get_sizeof): Handle TYPE_HAS_DYNAMIC_LENGTH. (typy_get_dynamic): Nw function. (type_object_getset): Add "dynamic". * NEWS: Add entry. gdb/doc/ChangeLog 2020-04-24 Tom Tromey <tromey@adacore.com> PR python/23662: * python.texi (Types In Python): Document new features. gdb/testsuite/ChangeLog 2020-04-24 Tom Tromey <tromey@adacore.com> PR python/23662: * gdb.ada/variant.exp: Add Python checks. * gdb.rust/simple.exp: Add dynamic type checks.
2020-04-15Fix makeinfo warnings in gdb.texinfo and python.texi docsArtur Shepilko1-1/+1
Building gdb-9.1 on a system that has an older version of makeinfo (4.8) shows the following warnings: ----------------- make[4]: Entering directory '/home/tester/gdb-9.1/build/gdb/doc' makeinfo --split-size=5000000 --split-size=5000000 -I ../../../gdb/doc/../../readline/readline/doc -I ../../../gdb/doc/../mi -I ../../../gdb/doc \ -o gdb.info ../../../gdb/doc/gdb.texinfo ../../../gdb/doc/gdb.texinfo:21867: warning: unlikely character [ in @var. ../../../gdb/doc/gdb.texinfo:21867: warning: unlikely character ] in @var. ../../../gdb/doc/gdb.texinfo:21868: warning: unlikely character [ in @var. ../../../gdb/doc/gdb.texinfo:21868: warning: unlikely character ] in @var. ../../../gdb/doc/gdb.texinfo:21869: warning: unlikely character [ in @var. ../../../gdb/doc/gdb.texinfo:21869: warning: unlikely character ] in @var. ../../../gdb/doc/gdb.texinfo:21872: warning: unlikely character [ in @var. ../../../gdb/doc/gdb.texinfo:21872: warning: unlikely character ] in @var. ../../../gdb/doc/gdb.texinfo:21874: warning: unlikely character [ in @var. ../../../gdb/doc/gdb.texinfo:21874: warning: unlikely character ] in @var. ../../../gdb/doc/gdb.texinfo:21876: warning: unlikely character [ in @var. ../../../gdb/doc/gdb.texinfo:21876: warning: unlikely character ] in @var. ../../../gdb/doc/gdb.texinfo:21879: warning: unlikely character [ in @var. ../../../gdb/doc/gdb.texinfo:21879: warning: unlikely character ] in @var. ../../../gdb/doc/gdb.texinfo:21931: warning: unlikely character [ in @var. ../../../gdb/doc/gdb.texinfo:21931: warning: unlikely character ] in @var. ../../../gdb/doc/gdb.texinfo:21933: warning: unlikely character [ in @var. ../../../gdb/doc/gdb.texinfo:21933: warning: unlikely character ] in @var. ../../../gdb/doc/gdb.texinfo:21936: warning: unlikely character [ in @var. ../../../gdb/doc/gdb.texinfo:21936: warning: unlikely character ] in @var. ../../../gdb/doc/gdb.texinfo:21939: warning: unlikely character [ in @var. ../../../gdb/doc/gdb.texinfo:21939: warning: unlikely character ] in @var. ../../../gdb/doc//python.texi:3297: warning: `.' or `,' must follow @xref, not `A'. make[4]: Leaving directory '/home/tester/gdb-9.1/build/gdb/doc' ----------------- These are thrown by expressions like `@var{[host]}`, intended to produce `[HOST]`. In that context this should instead be changed to `[@var{host}]`, which has the same effect but without the warnings. As for the warning in `python.texi`, there's period missing at the end of one `@xref{}` clause. Added. gdb/doc/ChangeLog: 2020-04-15 Artur Shepilko <nomadbyte@gmail.com> * gdb.texinfo: Transform @var{[host]} to [@var{host}]; this clears makeinfo warnings. * python.texi: Add a missing period trailing an @xref{} clause; this clears a makeinfo warning.
2020-03-04[gdb/doc] Remove trailing done from "Reading symbols from" linesTom de Vries1-2/+2
Since commit 3453e7e409 'Clean up "Reading symbols" output' we no longer print "done." after the "Reading symbols from" message: ... $ gdb -q a.out Reading symbols from a.out... (gdb) ... Update docs accordingly. Build on x86_64-linux. gdb/doc/ChangeLog: 2020-03-04 Tom de Vries <tdevries@suse.de> * gdb.texinfo: Remove trailing "done." in "Reading symbols from" lines. * python.texi: Same.
2020-02-22Allow TUI windows in PythonTom Tromey1-0/+105
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-10Multi-target: NEWS and user manualPedro Alves1-3/+3
This commit documents the new multi-target features in both NEWS and user manual. gdb/ChangeLog: 2020-01-10 Pedro Alves <palves@redhat.com> * NEWS: Mention multi-target debugging, "info connections", and "add-inferior -no-connection". gdb/doc/ChangeLog: 2020-01-10 Pedro Alves <palves@redhat.com> * gdb.texinfo (Starting): Say "current inferior not connected" instead of "GDB not connected". (Inferiors and Programs): Rename node to ... (Inferiors Connections and Programs): ... this. Update all references. Talk about multiple target connections. Update "info inferiors" info to mention the connections column. Describe "info connections". Document "add-inferior -no-connection". * guile.texi, python.texi: Update cross references.
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-12-14gdb/doc: Remove duplicate description of lookup_global_symbolAndrew Burgess1-14/+0
In this commit: commit 086baaf1346f07acfb6708e8c6cb79274241488b Date: Tue Oct 15 16:18:26 2019 +0100 gdb/python: Introduce gdb.lookup_static_symbols A duplicate description of gdb.lookup_global_symbol was accidentally added. This commit corrects this mistake and removes the duplicate. gdb/doc/ChangeLog: * python.texi (Symbols In Python): Remove duplicate description of gdb.lookup_global_symbol. Change-Id: I4457b42cf05bde39e5c0ff39f168af919cad1255
2019-12-10Minor fix to gdb.prompt documentationTom Tromey1-3/+2
I noticed that an example in the gdb.prompt documentation used the wrong kind of quotes -- because it is code, it should use a plain ASCII quotation mark. I also slightly shortened the sample text here, so it would more clearly fit on a single line. gdb/doc/ChangeLog 2019-12-10 Tom Tromey <tom@tromey.com> * python.texi (gdb.prompt): Use correct quotes in example. Shorten sample text. Change-Id: I4153928c0d88001244ad410f3943c952a6ebfeb1
2019-11-14[gdb/doc] Fix typosTom de Vries1-1/+1
Fix typos in gdb docs. gdb/doc/ChangeLog: 2019-11-14 Tom de Vries <tdevries@suse.de> * gdb.texinfo: Fix typos. * python.texi: Same. * stabs.texinfo: Same. Change-Id: I044d6788eeea48e4a9b73ee752e5aaf333e56a46
2019-11-10gdb/python: Introduce gdb.lookup_static_symbolsAndrew Burgess1-0/+35
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-11-10gdb/python: smarter symbol lookup for gdb.lookup_static_symbolAndrew Burgess1-0/+9
When using gdb.lookup_static_symbol I think that GDB should find static symbols (global symbol with static linkage) from the current object file ahead of static symbols from other object files. This means that if we have two source files f1.c and f2.c, and both files contains 'static int foo;', then when we are stopped in f1.c a call to 'gdb.lookup_static_symbol ("foo")' will find f1.c::foo, and if we are stopped in f2.c we would find 'f2.c::foo'. Given that gdb.lookup_static_symbol always returns a single symbol, but there can be multiple static symbols with the same name GDB is always making a choice about which symbols to return. I think that it makes sense for the choice GDB makes in this case to match what a user would get on the command line if they asked to 'print foo'. gdb/testsuite/ChangeLog: * gdb.python/py-symbol.c: Declare and call function from new py-symbol-2.c file. * gdb.python/py-symbol.exp: Compile both source files, and add new tests for gdb.lookup_static_symbol. * gdb.python/py-symbol-2.c: New file. gdb/doc/ChangeLog: * python.texi (Symbols In Python): Extend documentation for gdb.lookup_static_symbol. gdb/ChangeLog: * python/py-symbol.c (gdbpy_lookup_static_symbol): Lookup in static block of current object file first. Also fix typo in header comment. Change-Id: Ie55dbeb8806f35577b46015deecde27a0ca2ab64
2019-10-23Add a note for how to get the list of threadsChristian Biesinger1-0/+3
It's not immediately obvious how to get the list of threads, so add a note about that in the "Threads in Python" section. gdb/doc/ChangeLog: 2019-10-23 Christian Biesinger <cbiesinger@google.com> * python.texi (Threads In Python): Add a note for how to get the list of threads. Change-Id: I0fef8a7aff161fc347c09052319048c907a6e8c3
2019-10-07[gdb/doc] Fix some typosTom de Vries1-1/+1
Fix typos 'prevsiouly -> previously' and 'corresonding -> corresponding' in the docs. gdb/doc/ChangeLog: 2019-10-07 Tom de Vries <tdevries@suse.de> * gdb.texinfo: Fix typo. * guile.texi: Same. * python.texi: Same.
2019-08-05Add block['var'] accessorChristian Biesinger1-1/+6
Currently we support iteration on blocks; this patch extends that to make subscript access work as well. gdb/ChangeLog: 2019-08-05 Christian Biesinger <cbiesinger@google.com> * NEWS: Mention dictionary access on blocks. * python/py-block.c (blpy_getitem): New function. (block_object_as_mapping): New struct. (block_object_type): Use new struct for tp_as_mapping field. gdb/doc/ChangeLog: 2019-08-05 Christian Biesinger <cbiesinger@google.com> * python.texi (Blocks In Python): Document dictionary access on blocks. gdb/testsuite/ChangeLog: 2019-08-05 Christian Biesinger <cbiesinger@google.com> * gdb.python/py-block.exp: Test dictionary access on blocks.
2019-07-30[PR/24474] Add gdb.lookup_static_symbol to the python APIChristian Biesinger1-0/+19
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-29Add Objfile.lookup_{global,static}_symbol functionsChristian Biesinger1-0/+17
This is essentially the inverse of Symbol.objfile. This allows handling different symbols with the same name (but from different objfiles) and can also be faster if the objfile is known. gdb/ChangeLog: 2019-07-29 Christian Biesinger <cbiesinger@google.com> * NEWS: Mention new functions Objfile.lookup_{global,static}_symbol. * python/py-objfile.c (objfpy_lookup_global_symbol): New function. (objfpy_lookup_static_symbol): New function. (objfile_object_methods): Add new functions. gdb/doc/ChangeLog: 2019-07-29 Christian Biesinger <cbiesinger@google.com> * python.texi (Objfiles In Python): Document new functions Objfile.lookup_{global,static}_symbol. gdb/testsuite/ChangeLog: 2019-07-29 Christian Biesinger <cbiesinger@google.com> * gdb.python/py-objfile.c: Add global and static vars. * gdb.python/py-objfile.exp: Test new functions Objfile. lookup_global_symbol and lookup_static_symbol.
2019-07-20Make documentation of "python" command match actual behaviorKevin Buettner1-2/+0
The example in the documentation for the "python" command shows GDB outputting instructions for how to terminate a sequence of python commands entered from the command line. The documentation shows that the following two lines are being output, though this does not occur when actually using the "python" command from GDB: Type python script End with a line saying just "end". While display of this text might be helpful, GDB has several other commands which also use the "end" terminator that offer no such text. Examples include the "if" and "while" commands. For example, (gdb) if 1==1 >print "a" >end $1 = "a" This seems similar to doing: (gdb) python >print 23 >end 23 If we decide that we want the "python" command to print such a message, we should also adjust the behavior for other GDB commands which also use "end" to terminate a command list. I.e, if this decision is made, the "if" and "while" commands ought to also print similar messages. So, for the moment anyway, this commit adjusts the documentation of the python command to match its implementation. This patch was taken from a larger body of work originating from the Archer project. I haven't been able to determine its original author, though I did find a commit log from Jan Kratochvil (in the Archer repository) which suggests that the change had originally been made to gdb.texinfo, but got inadvertently dropped when the python related documentation was split out to python.texi. gdb/doc/ChangeLog: * python.texi (python command): Revise example to match command behavior.
2019-06-04Add an objfile getter to gdb.TypeChristian Biesinger via gdb-patches1-0/+5
This allows users of the Python API to find the objfile where a type was defined. gdb/ChangeLog: gdb/ChangeLog 2019-06-04 Christian Biesinger <cbiesinger@google.com> Add objfile property to gdb.Type. * gdb/NEWS: Mention Python API addition. * gdb/python/py-type.c (typy_get_objfile): New method. gdb/doc/ChangeLog 2019-06-04 Christian Biesinger <cbiesinger@google.com> * gdb/doc/python.texi: Document new gdb.Type.objfile property. gdb/testsuite/ChangeLog 2019-06-04 Christian Biesinger <cbiesinger@google.com> * gdb/testsuite/gdb.python/py-type.exp: Test for new gdb.Type.objfile property.
2019-05-10Document lazy computation for pretty-printer "children" methodTom Tromey1-0/+6
I found out recently that some users didn't know that the Python pretty-printers "children" method should compute its result lazily. This has been a good idea since the earliest days, but wasn't mentioned in the docs. This patch adds some text to this effect. gdb/doc/ChangeLog 2019-05-10 Tom Tromey <tromey@adacore.com> * python.texi (Pretty Printing API): Mention lazy computation for "children".
2019-04-29gdb: Introduce 'print max-depth' featureAndrew Burgess1-0/+8
Introduce a new print setting max-depth which can be set with 'set print max-depth DEPTH'. The default value of DEPTH is 20, but this can also be set to unlimited. When GDB is printing a value containing nested structures GDB will stop descending at depth DEPTH. Here is a small example: typedef struct s1 { int a; } s1; typedef struct s2 { s1 b; } s2; typedef struct s3 { s2 c; } s3; typedef struct s4 { s3 d; } s4; s4 var = { { { { 3 } } } }; The following table shows how various depth settings affect printing of 'var': | Depth Setting | Result of 'p var' | |---------------+--------------------------------| | Unlimited | $1 = {d = {c = {b = {a = 3}}}} | | 4 | $1 = {d = {c = {b = {a = 3}}}} | | 3 | $1 = {d = {c = {b = {...}}}} | | 2 | $1 = {d = {c = {...}}} | | 1 | $1 = {d = {...}} | | 0 | $1 = {...} | Only structures, unions, and arrays are replaced in this way, scalars and strings are not replaced. The replacement is counted from the level at which you print, not from the top level of the structure. So, consider the above example and this GDB session: (gdb) set print max-depth 2 (gdb) p var $1 = {d = {c = {...}}} (gdb) p var.d $2 = {c = {b = {...}}} (gdb) p var.d.c $3 = {b = {a = 3}} Setting the max-depth to 2 doesn't prevent the user from exploring deeper into 'var' by asking for specific sub-fields to be printed. The motivation behind this feature is to try and give the user more control over how much is printed when examining large, complex data structures. The default max-depth of 20 means that there is a change in GDB's default behaviour. Someone printing a data structure with 20 levels of nesting will now see '{...}' instead of their data, they would need to adjust the max depth, or call print again naming a specific field in order to dig deeper into their data structure. If this is considered a problem then we could increase the default, or even make the default unlimited. This commit relies on the previous commit, which added a new field to the language structure, this new field was a string that contained the pattern that should be used when a structure/union/array is replaced in the output, this allows languages to use a syntax that is more appropriate, mostly this will be selecting the correct types of bracket '(...)' or '{...}', both of which are currently in use. This commit should have no impact on MI output, expressions are printed through the MI using -var-create and then -var-list-children. As each use of -var-list-children only ever displays a single level of an expression then the max-depth setting will have no impact. This commit also adds the max-depth mechanism to the scripting language pretty printers following basically the same rules as for the built in value printing. One quirk is that when printing a value using the display hint 'map', if the keys of the map are structs then GDB will hide the keys one depth level after it hides the values, this ensures that GDB produces output like this: $1 = map_object = {[{key1}] = {...}, [{key2}] = {...}} Instead of this less helpful output: $1 = map_object = {[{...}] = {...}, [{...}] = {...}} This is covered by the new tests in gdb.python/py-nested-maps.exp. gdb/ChangeLog: * cp-valprint.c (cp_print_value_fields): Allow an additional level of depth when printing anonymous structs or unions. * guile/scm-pretty-print.c (gdbscm_apply_val_pretty_printer): Don't print either the top-level value, or the children if the max-depth is exceeded. (ppscm_print_children): When printing the key of a map, allow one extra level of depth. * python/py-prettyprint.c (gdbpy_apply_val_pretty_printer): Don't print either the top-level value, or the children if the max-depth is exceeded. (print_children): When printing the key of a map, allow one extra level of depth. * python/py-value.c (valpy_format_string): Add max_depth keyword. * valprint.c: (PRINT_MAX_DEPTH_DEFAULT): Define. (user_print_options): Initialise max_depth field. (val_print_scalar_or_string_type_p): New function. (val_print): Check to see if the max depth has been reached. (val_print_check_max_depth): Define new function. (show_print_max_depth): New function. (_initialize_valprint): Add 'print max-depth' option. * valprint.h (struct value_print_options) <max_depth>: New field. (val_print_check_max_depth): Declare new function. * NEWS: Document new feature. gdb/doc/ChangeLog: * gdb.texinfo (Print Settings): Document 'print max-depth'. * guile.texi (Guile Pretty Printing API): Document that 'print max-depth' can effect the display of a values children. * python.texi (Pretty Printing API): Likewise. (Values From Inferior): Document max_depth keyword. gdb/testsuite/ChangeLog: * gdb.base/max-depth.c: New file. * gdb.base/max-depth.exp: New file. * gdb.python/py-nested-maps.c: New file. * gdb.python/py-nested-maps.exp: New file. * gdb.python/py-nested-maps.py: New file. * gdb.python/py-format-string.exp (test_max_depth): New proc. (test_all_common): Call test_max_depth. * gdb.fortran/max-depth.exp: New file. * gdb.fortran/max-depth.f90: New file. * gdb.go/max-depth.exp: New file. * gdb.go/max-depth.go: New file. * gdb.modula2/max-depth.exp: New file. * gdb.modula2/max-depth.c: New file. * lib/gdb.exp (get_print_expr_at_depths): New proc.
2019-04-08Rename python function thread_from_thread_handle to thread_from_handleKevin Buettner1-2/+7
This renaming was done to stay consistent with the naming of the new gdb.InferiorThread.handle method. I had initially named it "thread_handle" but Tom Tromey suggested just "handle". The old name (thread_from_thread_handle) still works, but is marked as deprecated in comments in the code as well as in the documentation. I have some code which uses these functions. I very much like the brevity of the new names. gdb/doc/ChangeLog: * python.texi (Inferiors In Python): Rename Inferior.thread_from_thread_handle to Inferior.thread_from_handle. Add note about the former being deprecated. gdb/ChangeLog: * python/py-inferior.c (infpy_thread_from_thread_handle): Adjust comments to reflect renaming of thread_from_thread_handle to thread_from_handle. Adjust keywords. Fix type error message. (inferior_object_methods): Add thread_from_handle. Retain thread_from_thread_handle, but mark it as deprecated. testsuite/ChangeLog: * gdb.python/py-thrhandle.exp: Adjust tests to call thread_from_handle instead of thread_from_thread_handle.
generated by cgit v1.1 at 2025-03-03 13:45:29 +0000