From patchwork Mon Oct 27 03:10:33 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Victor Kamensky X-Patchwork-Id: 3386 Received: (qmail 5566 invoked by alias); 27 Oct 2014 03:10:48 -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 5358 invoked by uid 89); 27 Oct 2014 03:10:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f44.google.com Received: from mail-pa0-f44.google.com (HELO mail-pa0-f44.google.com) (209.85.220.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 27 Oct 2014 03:10:46 +0000 Received: by mail-pa0-f44.google.com with SMTP id bj1so976812pad.17 for ; Sun, 26 Oct 2014 20:10:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=AdpdJlmAGmdBeGYCzvZRgTsV79AFnn7+9dJOcG9te28=; b=XPmSLb00SyBjh0D0rkBOfvoe0QumMd7XiV4K4rv3ZvBaspHfUtVaknGibT6BKkgKlJ QjijED5CD89bVdLqfFlVGfcPYVgFGtESIDznFwpEnVfe3SJkKsxe19jzlCKHXbDpjbBr Yk3cigE7dprc6Sbk2V7YGkbknnXQ0g3Dm69XzM3z2lc9OkPPen061DLNSANosHFfQZ03 /+rlyleUYWfP+5Hn/v3mqRMr3YkEy/BlvPmiJd30Xzgo4cYP00qQ/7QyYmxLbUbgltzO pr5RDyjJYCfo77jXW1VeoOKvaha3PiMSWdERALyDgnti6K9v378eTrNzhQYaHe1FE3ad uHUw== X-Gm-Message-State: ALoCoQkCFs74Yvm7bW/T55YZ1pRUYPCgQdkufA9/lhgXFuw2mqjB2iCVNycZe5xlO6iXk1itzMA4 X-Received: by 10.66.187.234 with SMTP id fv10mr21171963pac.60.1414379444950; Sun, 26 Oct 2014 20:10:44 -0700 (PDT) Received: from kamensky-w530.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPSA id sb2sm9410723pbc.24.2014.10.26.20.10.43 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Oct 2014 20:10:44 -0700 (PDT) From: Victor Kamensky To: gdb-patches@sourceware.org, Yao Qi Cc: Andrew Pinski , victor.kamensky@linaro.org Subject: [PATCH V4 2/3] ARM: arm_breakpoint should be little endian form in case for arm BE8 Date: Sun, 26 Oct 2014 20:10:33 -0700 Message-Id: <1414379434-5217-3-git-send-email-victor.kamensky@linaro.org> In-Reply-To: <1414379434-5217-1-git-send-email-victor.kamensky@linaro.org> References: <1414379434-5217-1-git-send-email-victor.kamensky@linaro.org> tdep->arm_breakpoint, tdep->thumb_breakpoint, tdep->thumb2_breakpoint should be set le_ variants in case of arm BE8 code. Those instruciton sequences are writen to target with simple write_memory, without regarding gdbarch_byte_order_for_code. But in BE8 case even data memory is in big endian form, instructions are still in little endian form. Because of this issue there are many issues while running gdb test case in armv7b mode. For example gdb.arch/arm-disp-step.exp test fails because it gets SIGILL when displaced instrucion sequence reaches break instruction, which is in wrong byte order. Solution is to set tdep->xxx_breakpoint sequences in BE8 case (i.e when gdbarch_byte_order_for_code is BFD_ENDIAN_BIG. gdb/ChangeLog: 2014-10-21 Victor Kamensky * arm-linux-tdep.c (arm_linux_init_abi): Use info.byte_order_for_code to choose endianity of breakpoint instructions snippets. --- gdb/arm-linux-tdep.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gdb/arm-linux-tdep.c b/gdb/arm-linux-tdep.c index e3587f3..2e79658 100644 --- a/gdb/arm-linux-tdep.c +++ b/gdb/arm-linux-tdep.c @@ -1361,7 +1361,7 @@ arm_linux_init_abi (struct gdbarch_info info, linux_init_abi (info, gdbarch); tdep->lowest_pc = 0x8000; - if (info.byte_order == BFD_ENDIAN_BIG) + if (info.byte_order_for_code == BFD_ENDIAN_BIG) { if (tdep->arm_abi == ARM_ABI_AAPCS) tdep->arm_breakpoint = eabi_linux_arm_be_breakpoint;