aboutsummaryrefslogtreecommitdiff
path: root/gdb/python
AgeCommit message (Collapse)AuthorFilesLines
2024-07-15gdb: make objfile::pspace privateSimon Marchi1-1/+1
Rename to m_pspace, add getter. An objfile's pspace never changes, so no setter is necessary. Change-Id: If4dfb300cb90dc0fb9776ea704ff92baebb8f626
2024-06-24Rename symtab::fullnameTom Tromey1-2/+2
This renames symtab::fullname to m_fullname and adds new accessor methods.
2024-06-19[gdb/build] Redo poisoning of PyObject_CallMethodTom de Vries1-3/+5
In commit 764af878259 ("[gdb/python] Add typesafe wrapper around PyObject_CallMethod") I added poisoning of PyObject_CallMethod: ... /* Poison PyObject_CallMethod. The typesafe wrapper gdbpy_call_method should be used instead. */ template<typename... Args> PyObject * PyObject_CallMethod (Args...); ... The idea was that subsequent code would be forced to use gdbpy_call_method instead of PyObject_CallMethod. However, that caused build issues with gcc 14 and python 3.13: ... /usr/bin/ld: python/py-disasm.o: in function `gdb::ref_ptr<_object, gdbpy_ref_policy<_object> > gdbpy_call_method<unsigned int, long long>(_object*, char const*, unsigned int, long long)': /data/vries/gdb/src/gdb/python/python-internal.h:207:(.text+0x384f): undefined reference to `_object* PyObject_CallMethod<_object*, char*, char*, unsigned int, long long>(_object*, char*, char*, unsigned int, long long)' /usr/bin/ld: python/py-tui.o: in function `gdb::ref_ptr<_object, gdbpy_ref_policy<_object> > gdbpy_call_method<int>(_object*, char const*, int)': /data/vries/gdb/src/gdb/python/python-internal.h:207:(.text+0x1235): undefined reference to `_object* PyObject_CallMethod<_object*, char*, char*, int>(_object*, char*, char*, int)' /usr/bin/ld: python/py-tui.o: in function `gdb::ref_ptr<_object, gdbpy_ref_policy<_object> > gdbpy_call_method<int, int, int>(_object*, char const*, int, int, int)': /data/vries/gdb/src/gdb/python/python-internal.h:207:(.text+0x12b0): undefined reference to `_object* PyObject_CallMethod<_object*, char*, char*, int, int, int>(_object*, char*, char*, int, int, int)' collect2: error: ld returned 1 exit status ... Fix this by poisoning without using templates. Tested on x86_64-linux.
2024-06-19gdb/python/python-internal.h: avoid uninitialized constexprLancelot SIX1-6/+18
The following recent change introduced a regression when building using clang++: commit 764af878259768bb70c65bdf3f3285c2d6409bbd Date: Wed Jun 12 18:58:49 2024 +0200 [gdb/python] Add typesafe wrapper around PyObject_CallMethod The error message is: ../../gdb/python/python-internal.h:151:16: error: default initialization of an object of const type 'const char' constexpr char gdbpy_method_format; ^ = '\0' CXX python/py-block.o 1 error generated. make[2]: *** [Makefile:1959: python/py-arch.o] Error 1 make[2]: *** Waiting for unfinished jobs.... In file included from ../../gdb/python/py-auto-load.c:25: ../../gdb/python/python-internal.h:151:16: error: default initialization of an object of const type 'const char' constexpr char gdbpy_method_format; ^ = '\0' 1 error generated. make[2]: *** [Makefile:1959: python/py-auto-load.o] Error 1 In file included from ../../gdb/python/py-block.c:23: ../../gdb/python/python-internal.h:151:16: error: default initialization of an object of const type 'const char' constexpr char gdbpy_method_format; ^ = '\0' 1 error generated. This patch fixes this by changing gdbpy_method_format to be a templated struct, and only have its specializations define the static constexpr member "format". This way, we avoid having an uninitialized constexpr expression, regardless of it being instantiated or not. Reviewed-By: Tom de Vries <tdevries@suse.de> Change-Id: I5bec241144f13500ef78daea30f00d01e373692d
2024-06-13Add gdbpy_call_method overloads for gdbpy_ref<>Tom Tromey2-5/+14
This adds an overload of gdbpy_call_method that accepts a gdbpy_ref<>. This is just a small convenience. Reviewed-By: Tom de Vries <tdevries@suse.de>
2024-06-13Return gdbpy_ref<> from gdbpy_call_methodTom Tromey6-29/+29
This changes gdbpy_call_method to return a gdbpy_ref<>. This is slightly safer because it makes it simpler to correctly handle reference counts. Reviewed-By: Tom de Vries <tdevries@suse.de>
2024-06-12[gdb/python] Add typesafe wrapper around PyObject_CallMethodTom Tromey6-37/+79
In gdb/python/py-tui.c we have code like this: ... gdbpy_ref<> result (PyObject_CallMethod (m_window.get(), "hscroll", "i", num_to_scroll, nullptr)); ... The nullptr is superfluous, the format string already indicates that there's only one method argument. OTOH, passing no method args does use a nullptr: ... gdbpy_ref<> result (PyObject_CallMethod (m_window.get (), "render", nullptr)); ... Furthermore, choosing the right format string chars can be tricky. Add a typesafe wrapper around PyObject_CallMethod that hides these details, such that we can use the more intuitive: ... gdbpy_ref<> result (gdbpy_call_method (m_window.get(), "hscroll", num_to_scroll)); ... and: ... gdbpy_ref<> result (gdbpy_call_method (m_window.get (), "render")); ... Tested on x86_64-linux. Co-Authored-By: Tom de Vries <tdevries@suse.de> Approved-By: Tom Tromey <tom@tromey.com>
2024-06-11fix division by zero in target_read_string()Kilian Kilger1-1/+1
Under certain circumstances, a floating point exception in target_read_string() can happen when the type has been obtained by a call to stpy_lazy_string_elt_type(). In the latter function, a call to check_typedef() has been forgotten. This makes type->length = 0 in this case.
2024-06-10Make global_symbol_searcher::filenames privateTom Tromey1-8/+1
This patch renames global_symbol_searcher::filenames and makes it private, adding a new method to append a filename to the vector. This also cleans up memory management here, removing an alloca from rbreak, and removing a somewhat ugly SCOPE_EXIT from the Python code, in favor of having global_symbol_searcher manage the memory itself. Regression tested on x86-64 Fedora 38.
2024-06-10[gdb/python] Fix GDB_PY_{LL,LLU}_ARG on platform without long longTom de Vries1-2/+2
If in gdb/python/python-internal.h, we pretend to have a platform that doesn't support long long: ... -#ifdef HAVE_LONG_LONG +#if 0 ... I get on arm-linux: ... (gdb) placement_candidate() disassemble test^M Dump of assembler code for function test:^M 0x004004d8 <+0>: push {r11} @ (str r11, [sp, #-4]!)^M 0x004004dc <+4>: Python Exception <class 'ValueError'>: \ Buffer returned from read_memory is sized 0 instead of the expected 4^M ^M unknown disassembler error (error = -1)^M (gdb) FAIL: $exp: memory source api: second disassembler pass ... The problem is that gdb_py_longest is typedef-ed to long, but the corresponding format character GDB_PY_LL_ARG is defined to "L", meaning "long long" [1]. Fix this by using "l", meaning long instead. Likewise for GDB_PY_LLU_ARG. Tested on arm-linux. Approved-By: Tom Tromey <tom@tromey.com> PR python/31845 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31845 [1] https://docs.python.org/3/c-api/arg.html
2024-06-10[gdb/python] Fix gdb.python/py-disasm.exp on arm-linuxTom de Vries1-5/+7
After fixing test-case gdb.python/py-disasm.exp to recognize the arm nop: ... nop {0} ... we run into: ... disassemble test^M Dump of assembler code for function test:^M 0x004004d8 <+0>: push {r11} @ (str r11, [sp, #-4]!)^M 0x004004dc <+4>: add r11, sp, #0^M 0x004004e0 <+8>: nop {0}^M => 0x004004e4 <+12>: Python Exception <class 'ValueError'>: Buffer \ returned from read_memory is sized 0 instead of the expected 4^M ^M unknown disassembler error (error = -1)^M (gdb) FAIL: $exp: global_disassembler=ShowInfoRepr: disassemble test ... This is caused by this code in gdbpy_disassembler::read_memory_func: ... gdbpy_ref<> result_obj (PyObject_CallMethod ((PyObject *) obj, "read_memory", "KL", len, offset)); ... where len has type "unsigned int", while "K" means "unsigned long long" [1]. Fix this by using "I" instead, meaning "unsigned int". Also, offset has type LONGEST, which is typedef'ed to int64_t, while "L" means "long long". Fix this by using type gdb_py_longest for offset, in combination with format character "GDB_PY_LL_ARG". Likewise in disasmpy_info_read_memory. Tested on arm-linux. Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com> Approved-By: Tom Tromey <tom@tromey.com> PR python/31845 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31845 [1] https://docs.python.org/3/c-api/arg.html
2024-06-10[gdb/python] Note that python 3.6 assumes long long supportTom de Vries1-2/+13
Starting with python 3.6, support for platforms without long long support has been removed [1]. HAVE_LONG_LONG and PY_LONG_LONG are still defined, but only for compatibility, so stop relying on them. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> [1] https://github.com/python/cpython/issues/72148
2024-06-07gdb: make progspace::exec_filename private, add getter / setterSimon Marchi1-1/+1
Just like the title says... I think this makes things a bit clearer, for instance where the exec filename is set. It also makes the read call sites a bit nicer, avoiding the `.get ()`. Change-Id: If8b58ae8f6270c8a34b868f6ca06128c6671ea3c Approved-By: Tom Tromey <tom@tromey.com>
2024-06-06DAP: Handle "stepOut" request in outermost frameJohan Sternerup1-2/+2
Previously a "stepOut" request when in the outermost frame would result in a sucessful response even though gdb internally would reject the associated "finish" request, which means no stoppedEvent would ever be sent back to the client. Thus the client would believe the inferior was still running and as a consequence reject subsequent "next" and "stepIn" requests from the user. The solution is to execute the underlying finish command as a background command, i.e. `finish &`. If we're in the outermost frame an exception will be raised immediately, which we can now capture and report back to the client as success=False so then the absence of a `stopped` event is no longer a problem. We also make use of the `defer_stop_event` option to prevent a stop event from reaching the client until the response has been sent. Approved-By: Tom Tromey <tom@tromey.com>
2024-06-06DAP: Allow gdb exception in exec_and_log to propagateJohan Sternerup2-5/+8
This allows a request to specify that any gdb exception raised in exec_and_log within the gdb thread to be propagated back to the DAP thread (using the Canceller object as the orchestrator). Approved-By: Tom Tromey <tom@tromey.com>
2024-06-06DAP: Allow for deferring stop events from gdb threadJohan Sternerup2-7/+51
The existing `send_event_later()` method allows commands processed on the DAP thread to queue an event for execution until after the response has been sent to the client. We now introduce a corresponding method for use by the gdb thread. This method `send_event_maybe_later()` will queue the event just like `send_event_later()`, but only if it has been configured to do so by a new @request option `defer_stop_events`. As the name implies the functionality is currently only used for handling stop events. Approved-By: Tom Tromey <tom@tromey.com>
2024-06-04Return global scope from DAP scopes requestTom Tromey2-0/+101
A co-worker requested that the DAP code emit a scope for global variables. It's not really practical to do this for all globals, but it seemed reasonable to do this for globals coming from the frame's compilation unit. For Ada in particular, this is convenient as it exposes package-scoped variables. Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2024-06-04Convert DAP disassemble code to use Block hashingTom Tromey1-4/+3
This changes the DAP disassemble code to use the new Block hashing, storing the already-visited blocks in a set rather than a list.
2024-06-04Memoize gdb.Block and make them hashableTom Tromey1-64/+79
In subsequent patches, it's handy if gdb.Block is hashable, so it can be stored in a set or a dictionary. However, doing this in a straightforward way is not really possible, because a block isn't truly immutable -- it can be invalidated. And, while this isn't a real problem for my use case (in DAP the maps are only used during a single stop), it seemed error-prone. This patch instead takes the approach of using the gdb.Block's own object identity to allow hashing. This seems fine because the contents don't affect the hashing. In order for this to work, though, the blocks have to be memoized -- two requests for the same block must return the same object. This also allows (actually, requires) the simplification of the rich-compare method for blocks. Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
2024-06-04Put "source" into DAP scopeTom Tromey1-1/+4
I noticed a FIXME comment in the DAP code about adding a "source" field to a scope. This is easy to implement; I don't know why I didn't do this originally.
2024-06-03Enable call of overloaded subscript operator from pythonHannes Domani1-1/+5
If you try to use the overloaded subscript operator of a class in python, it fails like this: (gdb) py print(gdb.parse_and_eval('b')[5]) Traceback (most recent call last): File "<string>", line 1, in <module> gdb.error: Cannot subscript requested type. Error while executing Python code. This simply checks if such an operator exists, and calls it instead, making this possible: (gdb) py print(gdb.parse_and_eval('b')[5]) 102 'f' Approved-By: Tom Tromey <tom@tromey.com>
2024-06-03Allow calling of convenience functions with pythonHannes Domani1-5/+13
As mentioned in PR13326, currently when you try to call a convenience function with python, you get this error: (gdb) py print(gdb.convenience_variable("_isvoid")(3)) Traceback (most recent call last): File "<string>", line 1, in <module> RuntimeError: Value is not callable (not TYPE_CODE_FUNC or TYPE_CODE_METHOD). Error while executing Python code. So this extends valpy_call to handle TYPE_CODE_INTERNAL_FUNCTION as well, making this possible: (gdb) py print(gdb.convenience_variable("_isvoid")(3)) 0 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13326 Approved-By: Tom Tromey <tom@tromey.com>
2024-05-17Don't allow new-ui to start the TUITom Tromey1-0/+3
The TUI can't really work properly with new-ui, at least not as currently written. This patch changes new-ui to reject an attempt. Attempting to make a DAP ui this way is also now rejected. Regression tested on x86-64 Fedora 38. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29273 Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-05-10Add symbol, line, and location to DAP disassemble resultTom Tromey1-7/+52
The DAP spec allows a number of attributes on the resulting instructions that gdb currently does not emit. A user requested some of these, so this patch adds the 'symbol', 'line', and 'location' attributes. While the spec lets the implementation omit 'location' in some cases, it was simpler in the code to just always emit it, as then no extra tracking was needed.
2024-05-10Implement tp_richcompare for gdb.BlockTom Tromey1-1/+23
I noticed that two gdb.Block objects will never compare as equal with '=='. This patch fixes the problem by implementing tp_richcompare, as was done for gdb.Frame.
2024-05-10Simplify DAP make_source callersTom Tromey3-7/+8
A couple callers of make_source call basename by hand. Rather than add another caller like this, I thought it would be better to put this ability into make_source itself.
2024-05-10Remove FIXME from DAPTom Tromey1-1/+0
This patch removes one of the few DAP "FIXME" comments. This particular comment is already covered by PR dap/31036.
2024-05-10[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust (fixup)Tom de Vries1-9/+17
In commit 2236c5e384d ("[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust") I added this code in unwind_infopy_add_saved_register: ... if (value->optimized_out () || !value->entirely_available ()) ... which may throw c++ exceptions. This needs to be caught and transformed into a python exception. Fix this by using GDB_PY_HANDLE_EXCEPTION. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> Fixes: 2236c5e384d ("[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust")
2024-05-08[gdb/python] Make gdb.UnwindInfo.add_saved_register more robustTom de Vries1-0/+12
On arm-linux, until commit bbb12eb9c84 ("gdb/arm: Remove tpidruro register from non-FreeBSD target descriptions") I ran into: ... FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 5: \ backtrace when the unwind is broken at frame 5 ... What happens is the following: - the TestUnwinder from inline-frame-cycle-unwind.py calls gdb.UnwindInfo.add_saved_register with reg == tpidruro and value "<unavailable>", - pyuw_sniffer calls value->contents ().data () to access the value of the register, which throws an UNAVAILABLE_ERROR, - this causes the TestUnwinder unwinder to fail, after which another unwinder succeeds and returns the correct frame, and - the test-case fails because it's counting on the TestUnwinder to succeed and return an incorrect frame. Fix this by checking for !value::entirely_available as well as valued::optimized_out in unwind_infopy_add_saved_register. Tested on x86_64-linux and arm-linux. Approved-By: Andrew Burgess <aburgess@redhat.com> PR python/31437 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31437
2024-04-25gdb: remove gdbcmd.hSimon Marchi8-8/+8
Most files including gdbcmd.h currently rely on it to access things actually declared in cli/cli-cmds.h (setlist, showlist, etc). To make things easy, replace all includes of gdbcmd.h with includes of cli/cli-cmds.h. This might lead to some unused includes of cli/cli-cmds.h, but it's harmless, and much faster than going through the 170 or so files by hand. Change-Id: I11f884d4d616c12c05f395c98bbc2892950fb00f Approved-By: Tom Tromey <tom@tromey.com>
2024-04-23gdb: change return type of check_quit_flag to boolSimon Marchi1-3/+3
Change the return type of the check_quit_flag function to bool. Update a few related spots. Change-Id: I9d3a15d3f8651efb02c7d211f06222a592bd4184 Approved-By: Tom Tromey <tom@tromey.com>
2024-04-16[gdb/python] Throw MemoryError in inferior.read_memory if malloc failsTom de Vries2-3/+17
PR python/31631 reports a gdb internal error when doing: ... (gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff) utils.c:709: internal-error: virtual memory exhausted. A problem internal to GDB has been detected, further debugging may prove unreliable. ... Fix this by throwing a python MemoryError, such that we have instead: ... (gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff) Python Exception <class 'MemoryError'>: Error occurred in Python. (gdb) ... Likewise for DAP. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31631
2024-04-02Run isortTom Tromey33-65/+77
This patch is the result of running 'isort .' in the gdb directory. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-04-02Prepare gdb for isortTom Tromey2-0/+5
This patch prepares gdb for isort: it adds a couple of isort marker comments where needed, and it adds an isort clause to setup.cfg. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-04-02Do not use bare "except"Tom Tromey2-4/+4
flake8 warns about a bare "except". The docs point out that this will also catch KeyboardInterrupt and SystemExit exceptions, which is normally undesirable. Using "except Exception" catches everything reasonable, so this patch makes this change. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-04-02Suppress some "undefined" warnings from flake8Tom Tromey1-8/+9
flake8 warns about some identifiers in __init__.py, because it does not realize these come from the star-imported _gdb module. This patch suppresses these warnings.
2024-04-02Specify ImportError in styling.pyTom Tromey1-1/+1
styling.py has a long try/except surrounding most of the body. flake8 warns about the final bare "except". However, this except is really only there to catch the situation where the host doesn't have Pygments installed. This patch changes this to only catch ImportError. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-04-02Suppress star import errorsTom Tromey2-3/+5
flake8 warns about the "from _gdb.disassembler import *" line in disassembler.py, and a similar line from __init__.py. These line are needed to re-export names from the corresponding C++ module, so this patch applies the appropriate "noqa" flags. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-04-02Remove bare "except" from disassembler.pyTom Tromey1-14/+7
flake8 complains about a bare "except" in disassembler.py. In this case, the code purports to guard against some kind of user error involving data structure corruption. I think it's better here to just let the error occur -- py-disasm.c will show a stack trace in this case. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-04-02Remove unused import from gdb/__init__.pyTom Tromey1-1/+0
flake8 points out that the import of _gdb in gdb/__init__.py is unused. Remove it. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-04-02Ignore unsed import in dap/__init__.pyTom Tromey1-15/+17
flake8 warns about dap/__init__.py because it has a number of unused imports. Most of these are intentional: the import is done to ensure that the a DAP request is registered with the server object. This patch applies a "noqa" comment to these imports, and also removes one import that is truly unnecessary. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-04-02Fix flake8 errors in dap/server.pyTom Tromey1-1/+2
Commit 032d23a6 ("Fix stray KeyboardInterrupt after cancel") introduced some errors into dap/server.py. A function is called but not imported, and the wrong variable name is used. This patch corrects both errors. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-03-26gdb, gdbserver, gdbsupport: remove includes of early headersSimon Marchi50-50/+0
Now that defs.h, server.h and common-defs.h are included via the `-include` option, it is no longer necessary for source files to include them. Remove all the inclusions of these files I could find. Update the generation scripts where relevant. Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837 Approved-By: Pedro Alves <pedro@palves.net>
2024-03-19Fix two serious flake8 reportsTom Tromey1-15/+10
flake8 points out that some code in frame_filters.py is referring to undefined variables. In the first hunk, I've changed the code to match what other 'complete' methods do in this file. In the second hunk, I've simply removed the try/except -- if get_filter_priority fails, it will raise GdbError, which is already handled properly by gdb.
2024-03-19gdb/python: Fix segfault when iterating over empty linetableToby Lloyd Davies1-1/+2
symtab-> linetable () is set to null in buildsym_compunit::end_compunit_symtab_with_blockvector () if the symtab has no linetable. Attempting to iterate over this linetable using the Python API caused GDB to segfault. Approved-By: Tom Tromey <tom@tromey.com>
2024-03-18Set __file__ when source'ing a Python scriptTom Tromey1-10/+63
This patch arranges to set __file__ when source'ing a Python script. This fixes a problem that was introduced by the "source" rewrite, and then pointed out by Lancelot Six. Reviewed-by: Lancelot Six <lancelot.six@amd.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-03-14Remove 'if' from GDB_PY_HANDLE_EXCEPTIONTom Tromey5-42/+17
This removes the embedded 'if' from GDB_PY_HANDLE_EXCEPTION and GDB_PY_SET_HANDLE_EXCEPTION. I believe this 'if' was necessary with the old gdb try/catch macros, but it no longer is: these should only ever be called from a 'catch' block, where it's already known that an exception was thrown. Simon pointed out, though, that in a few spots, these were in facts called outside of 'catch' blocks. This patch cleans up these spots. I also found one spot where a redundant 'return nullptr' could be removed.
2024-03-09[gdb/python] Handle deprecation of PyErr_{Fetch,Restore} in 3.12Tom de Vries1-0/+26
Starting python version 3.12, PyErr_Fetch and PyErr_Restore are deprecated. Use PyErr_GetRaisedException and PyErr_SetRaisedException instead, for python >= 3.12. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-03-09[gdb/python] Normalize exceptions in gdbpy_err_fetchTom de Vries1-1/+14
With python 3.12, I run into: ... (gdb) PASS: gdb.python/py-block.exp: check variable access python print (block['nonexistent'])^M Python Exception <class 'KeyError'>: 'nonexistent'^M Error occurred in Python: 'nonexistent'^M (gdb) FAIL: gdb.python/py-block.exp: check nonexistent variable ... The problem is that that PyErr_Fetch returns a normalized exception, while the test-case matches the output for an unnormalized exception. With python 3.6, PyErr_Fetch returns an unnormalized exception, and the test passes. Fix this by: - updating the test-case to match the output for a normalized exception, and - lazily forcing normalized exceptions using PyErr_NormalizeException. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-03-09[gdb/python] Use gdbpy_err_fetch::{type,value} as gettersTom de Vries2-6/+15
Similar to gdbpy_err_fetch::value, add a getter gdbpy_err_fetch::type, and use both consistently to get gdbpy_err_fetch members m_error_value and m_error_type. Tested on aarch64-linux.