This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug gdb/20939] GDB aborts if there is an error in disassembly


https://sourceware.org/bugzilla/show_bug.cgi?id=20939

--- Comment #6 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Yao Qi <qiyao@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d8b49cf0c891d09dd58de05ad5cfe396b612cf3b

commit d8b49cf0c891d09dd58de05ad5cfe396b612cf3b
Author: Yao Qi <yao.qi@linaro.org>
Date:   Thu Jan 26 14:29:20 2017 +0000

    Don't throw exception in dis_asm_memory_error

    Hi,
    GDB calls some APIs from opcodes to do disassembly and provide some
    call backs.  This model makes troubles on C++ exception unwinding,
    because GDB is a C++ program, and opcodes is still compiled as C.
    As we can see, frame #10 and #12 are C++, while #frame 11 is C,

     #10 0x0000000000544228 in memory_error (err=TARGET_XFER_E_IO,
memaddr=<optimized out>) at ../../binutils-gdb/gdb/corefile.c:237
     #11 0x00000000006b0a54 in print_insn_aarch64 (pc=0, info=0xffffffffeeb0)
at ../../binutils-gdb/opcodes/aarch64-dis.c:3185
     #12 0x0000000000553590 in gdb_pretty_print_insn
(gdbarch=gdbarch@entry=0xbbceb0, uiout=uiout@entry=0xbc73d0,
di=di@entry=0xffffffffeeb0,
        insn=0xffffffffed40, insn@entry=0xffffffffed90, flags=flags@entry=0,

    C++ exception unwinder can't go across frame #11 unless it has
    unwind table.  However, C program on many architectures doesn't
    have it in default.  As a result, GDB aborts, which is described
    in PR 20939.

    This is not the first time we see this kind of problem.  We've
    had a commit 89525768cd086a0798a504c81fdf7ebcd4c904e1
    "Propagate GDB/C++ exceptions across readline using sj/lj-based TRY/CATCH".
    We can fix the disassembly bug in a similar way, this is the option one.

    Since opcodes is built with gdb, we fix this problem in a different
    way as we did for the same issue with readline.  Instead of throwing
    exception in dis_asm_memory_error, we record the failed memory
    address, and throw exception when GDB returns from opcodes disassemblers.

    gdb:

    2017-01-26  Yao Qi  <yao.qi@linaro.org>
            Pedro Alves  <palves@redhat.com>

        PR gdb/20939
        * disasm.c (gdb_disassembler::dis_asm_memory_error): Don't
        call memory_error, save memaddr instead.
        (gdb_disassembler::print_insn): If gdbarch_print_insn returns
        negative, cal memory_error.
        * disasm.h (gdb_disassembler) <m_err_memaddr>: New field.

    gdb/testsuite:

    2017-01-26  Yao Qi  <yao.qi@linaro.org>

        * gdb.base/all-architectures.exp.in (do_arch_tests): Test
        disassemble on address 0.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]