From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107481 invoked by alias); 17 Jan 2017 14:42:41 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 107470 invoked by uid 89); 17 Jan 2017 14:42:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=backs, 79613, Hx-languages-length:4639, Weve X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 17 Jan 2017 14:42:30 +0000 Received: from svr-orw-mbx-03.mgc.mentorg.com ([147.34.90.203]) by relay1.mentorg.com with esmtp id 1cTUxx-0007gX-0O from Luis_Gustavo@mentor.com ; Tue, 17 Jan 2017 06:42:29 -0800 Received: from [172.30.8.199] (147.34.91.1) by svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 17 Jan 2017 06:42:25 -0800 Subject: Re: [PATCH 6/6] Don't throw exception in dis_asm_memory_error References: <1484051178-16013-1-git-send-email-yao.qi@linaro.org> <1484560977-8693-1-git-send-email-yao.qi@linaro.org> <1484560977-8693-7-git-send-email-yao.qi@linaro.org> To: Yao Qi , Reply-To: Luis Machado From: Luis Machado Message-ID: Date: Tue, 17 Jan 2017 14:42:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <1484560977-8693-7-git-send-email-yao.qi@linaro.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: svr-orw-mbx-02.mgc.mentorg.com (147.34.90.202) To svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00326.txt.bz2 On 01/16/2017 04:02 AM, Yao Qi wrote: > 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=) 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-10 Yao Qi > Pedro Alves > > 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) : New field. > > gdb/testsuite: > > 2017-01-10 Yao Qi > > * gdb.base/all-architectures.exp.in (do_arch_tests): Test > disassemble on address 0. > --- > gdb/disasm.c | 13 +++++++++++-- > gdb/disasm.h | 1 + > gdb/testsuite/gdb.base/all-architectures.exp.in | 3 +++ > 3 files changed, 15 insertions(+), 2 deletions(-) > > diff --git a/gdb/disasm.c b/gdb/disasm.c > index f31d8d3..8c8c42e 100644 > --- a/gdb/disasm.c > +++ b/gdb/disasm.c > @@ -135,7 +135,10 @@ void > gdb_disassembler::dis_asm_memory_error (int err, bfd_vma memaddr, > struct disassemble_info *info) > { > - memory_error (TARGET_XFER_E_IO, memaddr); > + gdb_disassembler *self > + = static_cast(info->application_data); > + > + self->m_err_memaddr = memaddr; > } > > /* Like print_address with slightly different parameters. */ > @@ -765,7 +768,8 @@ fprintf_disasm (void *stream, const char *format, ...) > gdb_disassembler::gdb_disassembler (struct gdbarch *gdbarch, > struct ui_file *file, > di_read_memory_ftype read_memory_func) > - : m_gdbarch (gdbarch) > + : m_gdbarch (gdbarch), > + m_err_memaddr (0) > { > init_disassemble_info (&m_di, file, fprintf_disasm); > m_di.flavour = bfd_target_unknown_flavour; > @@ -792,8 +796,13 @@ int > gdb_disassembler::print_insn (CORE_ADDR memaddr, > int *branch_delay_insns) > { > + m_err_memaddr = 0; > + > int length = gdbarch_print_insn (arch (), memaddr, &m_di); > > + if (length < 0) > + memory_error (TARGET_XFER_E_IO, m_err_memaddr); > + > if (branch_delay_insns != NULL) > { > if (m_di.insn_info_valid) > diff --git a/gdb/disasm.h b/gdb/disasm.h > index 5122fa3..8e0b9f9 100644 > --- a/gdb/disasm.h > +++ b/gdb/disasm.h > @@ -63,6 +63,7 @@ protected: > private: > struct gdbarch *m_gdbarch; > struct disassemble_info m_di; > + CORE_ADDR m_err_memaddr; > > static int dis_asm_read_memory (bfd_vma memaddr, gdb_byte *myaddr, > unsigned int len, > diff --git a/gdb/testsuite/gdb.base/all-architectures.exp.in b/gdb/testsuite/gdb.base/all-architectures.exp.in > index c7615ac..50a615c 100644 > --- a/gdb/testsuite/gdb.base/all-architectures.exp.in > +++ b/gdb/testsuite/gdb.base/all-architectures.exp.in > @@ -152,6 +152,9 @@ proc print_floats {} { > > proc do_arch_tests {} { > print_floats > + > + gdb_test_internal "disassemble 0x0,+4" \ > + "Cannot access memory at address 0x0" I think you missed the comment you had proposed? # GDB can't access any memory because there is no live inferior. I take it we have no loaded executable as well? Otherwise we could eventually read data from the executable file, which wouldn't yield an error. > } > > # Given we can't change arch, osabi, endianness, etc. atomically, we >