[Bug python/31845] [gdb/python, arm] FAIL: gdb.python/py-disasm.exp: global_disassembler=ShowInfoRepr: disassemble test
cvs-commit at gcc dot gnu.org
sourceware-bugzilla@sourceware.org
Mon Jun 10 15:53:04 GMT 2024
https://sourceware.org/bugzilla/show_bug.cgi?id=31845
--- Comment #4 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=58a628530ee68fe705b443947643037319e7d44e
commit 58a628530ee68fe705b443947643037319e7d44e
Author: Tom de Vries <tdevries@suse.de>
Date: Mon Jun 10 17:53:30 2024 +0200
[gdb/python] Fix GDB_PY_{LL,LLU}_ARG on platform without long long
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
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the Gdb-prs
mailing list