From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66417 invoked by alias); 5 Aug 2015 18:03:03 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 66348 invoked by uid 89); 5 Aug 2015 18:03:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 X-HELO: mail-qg0-f98.google.com Received: from mail-qg0-f98.google.com (HELO mail-qg0-f98.google.com) (209.85.192.98) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 05 Aug 2015 18:03:01 +0000 Received: by qgi15 with SMTP id 15so2606922qgi.0 for ; Wed, 05 Aug 2015 11:02:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-transfer-encoding:content-type; bh=kuGYizCiy84Wpha0ajfSPxsbwRBM0FmtU4b/RhjfaXE=; b=JOhlPoTTEAJFZm368EdacWt8kVXCNNAs+NfnpDT0AVH68ewbeAWRx1QD9lRWkn5pXt NQDAbX0qFioqhpNWKARY9zXa1OrYJZ3Qoeh+0bmCclVM0PJX+WyuhsllDfO2yaNp4SWN xPGpyrMXv3Y5fid/aLK+JVCGGnmGnFVfG5khzGjI4JCSQ0P+YdoVnR9xdzkzyUTYZvwJ QJgwvk/UKEsy/alhWN8Bntl2L7DZSmzJRxdztrjAKQa736InifyLLkVdJ2hWl0Arra/S GY771urJM95uH+fs1lh9rKMeZQLMOEi6T8Kq3sP+JOxPniTBf1jidOf0CrxxrN5wS+AN YKNA== X-Gm-Message-State: ALoCoQlgD2HPlBmmX4jftJJbmrljS2BPQL/qGg7kkZVd3uphSaIig4+Ud2IlBM1htSvNBsAHtorDNjdYIdAsBbIjmoxlkdsRaQ== X-Received: by 10.107.137.87 with SMTP id l84mr13369337iod.119.1438797778884; Wed, 05 Aug 2015 11:02:58 -0700 (PDT) Received: from smtp02a.notes.lexmark.com ([192.146.101.8]) by smtp-relay.gmail.com with ESMTP id u9sm240534igb.0.2015.08.05.11.02.58 for ; Wed, 05 Aug 2015 11:02:58 -0700 (PDT) X-Relaying-Domain: lexmark.com Received: from lxkssmtp2e.lex.lexmark.com (smtp5b.notes.lexmark.com [157.184.50.112]) by smtp02a.notes.lexmark.com (Postfix) with ESMTP id AC00D139BFD for ; Wed, 5 Aug 2015 14:02:58 -0400 (EDT) Received: from seshat.lpdev.prtdev.lexmark.com ([10.199.21.28]) by lxkssmtp2e.lex.lexmark.com (Lotus Domino Release 6.5.5) with ESMTP id 2015080514025732-2430380 ; Wed, 5 Aug 2015 14:02:57 -0400 Received: from khan.lpdev.prtdev.lexmark.com (khan.lpdev.prtdev.lexmark.com [157.184.138.94]) by seshat.lpdev.prtdev.lexmark.com (Postfix) with ESMTP id 40A0E1940004 for ; Wed, 5 Aug 2015 14:02:57 -0400 (EDT) Message-ID: <55C24FD0.8010007@lexmark.com> Date: Wed, 05 Aug 2015 18:03:00 -0000 From: John Breitenbach User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: gdb@sourceware.org Subject: gdb won't single-step over ARM integer divide opcode X-LPDEV-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 40A0E1940004.A92EA X-LPDEV-MailScanner: Found to be clean X-LPDEV-MailScanner-From: breiten@lexmark.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=utf-8; format=flowed X-SW-Source: 2015-08/txt/msg00008.txt.bz2 I'm trying to debug a program compiled for a cortex-a53 using gcc-4.9.3 with gdb-7.9.1, and when I attempt to single-step through an sdiv opcode, gdb won't step. And it gives me a message about being unable to access memory: 1: x/i $pc => 0x8310 : sdiv r2, r2, r4 Cannot access memory at address 0xffffd8f0 I did some debugging and have found that the function, arm_get_next_pc_raw, inappropriately decodes this opcode as a load into the PC register. (bits 24..27 are 7, bit 20 is set, and the dest register appears to be the PC. Binutils's logic to disassemble the sdiv/udiv opcodes has opcode & 0x0ff0f0f0 = 0x0710f010 (with bit 21 distinguishing between udiv and sdiv) I've come up with the following patch which makes my situation work. But I don't know how complete it is, as there may be other newer opcodes which fall into the formerly undefined instruction space. Also, the comment "byte write to PC" around line 4930 seems wrong, as the check for bit 22 a few lines earlier catches that situation, and what's left is word writes to the PC." John --- gdb/arm-tdep.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c index 8e9552a..79da43e 100644 --- a/gdb/arm-tdep.c +++ b/gdb/arm-tdep.c @@ -4912,10 +4912,17 @@ arm_get_next_pc_raw (struct frame_info *frame, CORE_ADDR pc) break; } + case 0x7: + /* sdiv/udiv using masks from binutils/opcodes/arm-dis.c, + * otherwise, we think sdiv/udiv is a write to pc reg + */ + if( (this_instr & 0x0fd0f0f0) == 0x0710f010) + break; + /* intentional fall-though to case 4..6 */ + case 0x4: case 0x5: /* data transfer */ case 0x6: - case 0x7: if (bit (this_instr, 20)) { /* load */ -- 1.9.3