From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42297 invoked by alias); 14 Dec 2016 17:31:23 -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 41734 invoked by uid 89); 14 Dec 2016 17:31:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=unwinding X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 14 Dec 2016 17:31:21 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6981F6CB45; Wed, 14 Dec 2016 17:31:20 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uBEHVJ0X005953; Wed, 14 Dec 2016 12:31:19 -0500 Subject: Re: [RFC] PR 20939: Handle error in disassembly To: Yao Qi , gdb-patches@sourceware.org References: <20161212104825.GA25542@E107787-LIN> From: Pedro Alves Message-ID: Date: Wed, 14 Dec 2016 17:31:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161212104825.GA25542@E107787-LIN> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-12/txt/msg00298.txt.bz2 On 12/12/2016 10:48 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. > > Alternatively, we can do more changes in opcodes, because opcodes is > built together with gdb. Don't throw exception in dis_asm_memory_error, > and only throw exception if the return value of print_insn_$ARCH is -1 > in GDB. This is the option two, which is demonstrated by the patch > below. This requires every print_insn_$ARCH function return -1 on > memory error, but msp430 and m68k don't follow this convention yet. > > Which option do you prefer? If we prefer option one, the change is > only within the GDB scope. If we prefer option two, it goes out to > opcodes, and I'll bring the discussion to binutils. I prefer this > one. Did you try to find the discussions around when the current interface based on throwing (using longjmp at the time) was added? Maybe the "return -1" option was considered back then, but discarded for some reason? E.g., looks like simply "return -1" would lose the actual address that failed to be read, in case opcodes does several reads in sequence and its not the first that fails. We could add some other means to get at that, of course. > > Note that, no matter which option do we take, the fix should be > backported to 7.12 branch, in which GDB can still be built as a C > program. > Thanks, Pedro Alves