From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23133 invoked by alias); 25 Jan 2013 17:59:04 -0000 Received: (qmail 23124 invoked by uid 22791); 25 Jan 2013 17:59:04 -0000 X-SWARE-Spam-Status: No, hits=-7.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_GJ X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 25 Jan 2013 17:58:28 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r0PHwQ64009464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Jan 2013 12:58:26 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r0PHwPcj026438; Fri, 25 Jan 2013 12:58:25 -0500 Message-ID: <5102C7C0.50209@redhat.com> Date: Fri, 25 Jan 2013 17:59:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Marcus Shawcroft CC: "gdb-patches@sourceware.org" Subject: Re: [PATCH] aarch64-tdep basic port. References: <51028E3D.4030708@arm.com> In-Reply-To: <51028E3D.4030708@arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2013-01/txt/msg00639.txt.bz2 On 01/25/2013 01:53 PM, Marcus Shawcroft wrote: > By default we are not assuming any specific libc and hence not installing a longjmp handler via set_gdbarch_get_longjmp_target. I see. >>> +/* Implement the "addr_bits_remove" gdbarch method. */ >>> + >>> +static CORE_ADDR >>> +aarch64_addr_bits_remove (struct gdbarch *gdbarch, CORE_ADDR val) >>> +{ >>> + /* All instructions are 4-byte aligned. */ >>> + return val & ~(CORE_ADDR) 0x3; >>> +} >> >> Excuse the ignorance, but why do you need this? Does >> Aarch64 do any magic low address encoding, like arm/thumb? > > In the AArch64 execution state all instructions are 4 byte aligned with the least significant two bits reserved. Okay. Seems odd to me to just be clear the low bits and doing nothing else if they're "reserved", instead of waiting until they do have some meaning (at which point GDB will necessarily need to learn to do something about them). Does actually end up seeing non-4 bytes instructions today somehow? -- Pedro Alves