[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