The GDB provided by HPE on HP-UX contains a modified version string. Therefore
the tests fail. Adapt the regex to match that string.
Patch by Michael Osipov.
Co-Authored-by: Michael Osipov <michael.osipov@siemens.com>
Add functions with various calling conventions to `_testcapi`, expose them as module-level functions, bound methods, class methods, and static methods, and test calling them and introspecting them through GDB.
https://bugs.python.org/issue37499
Co-authored-by: Jeroen Demeyer <J.Demeyer@UGent.be>
Automerge-Triggered-By: @pganssle
Replace test.support.run_unittest() with unittest.main()
to automatically discover test cases, instead of having
an maintaing manually a list which may be incomplete.
Remove also an unused variable.
test_gdb no longer fails if it gets an "unexpected" message on
stderr: it now ignores stderr. The purpose of test_gdb is to test
that python-gdb.py commands work as expected, not to test gdb.
As it changes the way functions are called, the PEP 590 implementation
skipped the functions that the GDB integration is looking for
(by name) to find function calls.
Looking for the new helper `cfunction_call_varargs` hopefully fixes the
tests, and thus buildbots.
The changed frame nuber in test_gdb is due to there being fewer
C calls when calling a built-in method.
When Python is built with the intel control-flow protection flags,
-mcet -fcf-protection, gdb is not able to read the stack without
actually jumping inside the function. This means an extra
'next' command is required to make the $pc (program counter)
enter the function and make the stack of the function exposed to gdb.
Co-Authored-By: Marcel Plch <gmarcel.plch@gmail.com>
(cherry picked from commit 9b7c74ca32)
We cannot simply call locale.getpreferredencoding() here,
as GDB might have been linked against a different version
of Python with a different encoding and coercion policy
with respect to PEP 538 and PEP 540.
Thanks to Victor Stinner for a hint on how to fix this.
Sometimes some versions of the shared libraries that are part of the
traceback are compiled in optimised mode and the Program Counter (PC)
is not present, not allowing gdb to walk the frames back. When this
happens, the Python bindings of gdb raise an exception, making the
test impossible to succeed.
When Python is built with the intel control-flow protection flags,
-mcet -fcf-protection, gdb is not able to read the stack without
actually jumping inside the function. This means an extra
'next' command is required to make the $pc (program counter)
enter the function and make the stack of the function exposed to gdb.
