From patchwork Mon Dec 12 10:48:25 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yao Qi X-Patchwork-Id: 18383 Received: (qmail 57017 invoked by alias); 12 Dec 2016 10:48:58 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 56774 invoked by uid 89); 12 Dec 2016 10:48:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-1.5 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM, SPF_PASS autolearn=no version=3.3.2 spammy==e5=b0=a7, troubles?= X-HELO: mail-wm0-f65.google.com Received: from mail-wm0-f65.google.com (HELO mail-wm0-f65.google.com) (74.125.82.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Dec 2016 10:48:46 +0000 Received: by mail-wm0-f65.google.com with SMTP id m203so10341115wma.3 for ; Mon, 12 Dec 2016 02:48:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:content-transfer-encoding:user-agent; bh=YraNrs3zZ7q3E12HK5P3NKRA5EyXeyApgoOKBn83nWM=; b=XHS4aLEElMpviYMZ/PGQ+CGKhTho8yzPyhfNZMdYuSU0vw+6jXGVnGp5QVEnauId17 hgyJ45RC/wC4ZFKt6Awa7qSz+DFuXX9b8lWjhRKbXPxL2XI9IDd0MU1DHo0MSDeOvmA7 jqNCMPI18HYADBvwmXSDkfqhnmqAOdBc59o4ToF7gTWKsDN16E9+KalqS9xPDya4qyPY 63nbkYGC6IRXHuaq2whrg53Y1Q8qRvmXW0oTmRJ7Sotmw8voiv6jx9yHKQ/2SerRUOC2 f05RXHnsCILym4vlg6wz72xLNF3MOS/yItUJo516XdaJhZDftXkB1bbRIamUdJ28vHvw S9Og== X-Gm-Message-State: AKaTC03pkbM/s82gjI081gFzsjmnlOjxWfDa9CWl+Jf5/r1cTLjaZGnaEZk04Id3IRGRwQ== X-Received: by 10.28.73.136 with SMTP id w130mr8278236wma.82.1481539724656; Mon, 12 Dec 2016 02:48:44 -0800 (PST) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id js10sm56557202wjb.19.2016.12.12.02.48.43 for (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 12 Dec 2016 02:48:44 -0800 (PST) Date: Mon, 12 Dec 2016 10:48:25 +0000 From: Yao Qi To: gdb-patches@sourceware.org Subject: [RFC] PR 20939: Handle error in disassembly Message-ID: <20161212104825.GA25542@E107787-LIN> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes 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. 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. diff --git a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c index 0175630..4f5f056 100644 --- a/gdb/aarch64-tdep.c +++ b/gdb/aarch64-tdep.c @@ -1771,8 +1771,15 @@ aarch64_dwarf_reg_to_regnum (struct gdbarch *gdbarch, int reg) static int aarch64_gdb_print_insn (bfd_vma memaddr, disassemble_info *info) { + int ret; + info->symbols = NULL; - return print_insn_aarch64 (memaddr, info); + ret = print_insn_aarch64 (memaddr, info); + + if (ret == -1) + memory_error (TARGET_XFER_E_IO, memaddr); + + return ret; } /* AArch64 BRK software debug mode instruction. diff --git a/gdb/disasm.c b/gdb/disasm.c index 6f9f5f9..437b64c 100644 --- a/gdb/disasm.c +++ b/gdb/disasm.c @@ -137,7 +137,7 @@ static void dis_asm_memory_error (int err, bfd_vma memaddr, struct disassemble_info *info) { - memory_error (TARGET_XFER_E_IO, memaddr); + /*memory_error (TARGET_XFER_E_IO, memaddr);*/ } /* Like print_address with slightly different parameters. */