From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60480 invoked by alias); 8 Sep 2015 08:20:14 -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 60461 invoked by uid 89); 8 Sep 2015 08:20:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f43.google.com Received: from mail-pa0-f43.google.com (HELO mail-pa0-f43.google.com) (209.85.220.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 08 Sep 2015 08:20:11 +0000 Received: by pacfv12 with SMTP id fv12so120752692pac.2 for ; Tue, 08 Sep 2015 01:20:09 -0700 (PDT) X-Received: by 10.68.135.194 with SMTP id pu2mr56158023pbb.131.1441700409295; Tue, 08 Sep 2015 01:20:09 -0700 (PDT) Received: from E107787-LIN (power-aix.osuosl.org. [140.211.15.154]) by smtp.gmail.com with ESMTPSA id pp9sm2375074pdb.40.2015.09.08.01.20.06 (version=TLS1_2 cipher=AES128-SHA256 bits=128/128); Tue, 08 Sep 2015 01:20:08 -0700 (PDT) From: Yao Qi To: Richard Earnshaw Cc: Yao Qi , gdb-patches@sourceware.org, pinskia@gmail.com, catalin.udma@freescale.com Subject: Re: [PATCH] aarch64-core.xml: 32-bit cpsr -> 64-bit pstate References: <1441284969-30465-1-git-send-email-yao.qi@linaro.org> <55EE13C3.6000008@foss.arm.com> Date: Tue, 08 Sep 2015 08:20:00 -0000 In-Reply-To: <55EE13C3.6000008@foss.arm.com> (Richard Earnshaw's message of "Mon, 7 Sep 2015 23:46:27 +0100") Message-ID: <86si6p726k.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00083.txt.bz2 Richard Earnshaw writes: > Won't this also break any situation where the gdbserver knowledge is > embedded in a HW stub? You're assuming that we can just update all > those servers and everything will be fine and dandy. I don't think we > can't just change this arbitrarily. Yes, it will break any existing debugging stubs, including old gdbserver and jtag probes, which think the register in the target description (cpsr, psate or whatever) is 32-bit. However, I don't assume "we can just update all those servers and everything will be fine and dandy". As I said in the first mail, this change will break the compatibility. AArch64 is still a new architecture, and there isn't much compatibility burden as other old archs have. Under this context, I think correctness is more important than compatibility. If we don't fix it now, we can't fix it forever. So it isn't an arbitrary change. We did change the size of the register in the target description to 64-bit back and forth in 2013 and 2014, but I don't hear any complaints on this from HW jtag probes providers. > > I think kgdb should do what everyone else has been doing and simply > return the bottom 32 bits. I think kgdb is correct. I don't know what "everyone else" is. As far as I can see, openocd doesn't support aarch64 now, but there are some patches to add aarch64 support http://openocd.zylin.com/#/c/2501/14 the register (named CPSR in the openocd patches) is 64-bit, which looks right to me. --=20 Yao (=E9=BD=90=E5=B0=A7)