From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20887 invoked by alias); 20 Jun 2011 16:14:55 -0000 Received: (qmail 20876 invoked by uid 22791); 20 Jun 2011 16:14:53 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from service87.mimecast.com (HELO service87.mimecast.com) (94.185.240.25) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Mon, 20 Jun 2011 16:14:39 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Mon, 20 Jun 2011 17:14:35 +0100 Received: from [10.1.77.49] ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jun 2011 17:14:32 +0100 Message-ID: <4DFF71E2.5040402@arm.com> Date: Mon, 20 Jun 2011 16:14:00 -0000 From: Matthew Gretton-Dann User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18pre) Gecko/20110608 Lightning/1.0b3pre Lanikai/3.1.11pre MIME-Version: 1.0 To: "noloader@gmail.com" CC: GDB Users Subject: Re: Question on ARM/Thumb-16 Disassembly References: In-Reply-To: X-MC-Unique: 111062017143502701 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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 X-SW-Source: 2011-06/txt/msg00121.txt.bz2 Jeffrey, On 20/06/11 16:35, Jeffrey Walton wrote: > Hi All, > > A couple of questions for ARM/Thumb-2. I'm working on a live iPhone, > so I'm using Apple's GAS. It would be useful if you could give the command line you are using - as=20 I can't give precise answers without that info. Most of the comments I=20 make below are based upon the behaviour of the vanilla FSF tools, Apple=20 may have changed their behaviours in ways I am unaware of. > I've got a function generated for Thumb-16 which performs a branch > (immediately after an ADD) based on Carry. For some reason, I'm > getting unexpected results after the ADD - the carry flag is always > high (ie, CY =3D 1 in CPSR), even when adding 0 + 0, 1 + 1, etc. > > Under GDB, I perform a disassembly looking for something I might have > munged (or unexpected code generation and interactions). The first > thing I noticed is some instructions are 4 bytes despite being in > Thumb-16 mode (shown below). For example, the MOV at 0x00002334 is 4 > bytes. > > (1) Has anyone encountered a situation where a status flag gets > pinned? The ARM Instruction Reference states the status flags are > updated in Thumb mode (except when one or more high registers are > specified as operands). There are two types of assembly language syntax in GAS for ARM: 1. 'divided' syntax - where add instruction has different semantics=20 depending on whether you are in Thumb or ARM state. 2. 'unified' syntax - where the add instruction has the same semantics=20 in ARM and Thumb state. (Look for a .syntax directive in your assembly source). My guess is that you have written something like the following in your=20 assembly code: add r0, r1, r2 Which would set the flags in Thumb-1 code when using divided syntax but=20 does not when using unified syntax. So the fix is to do the following instead: adds r0, r1, r2 [The additional 's' means set the flags]. > (2) Are 4 byte instructions expected when GCC generates Thumb-16 code? > The ARM Instruction Reference seems to state otherwise. GCC will generate code using all the features available in the=20 instruction set for the CPU/architecture it is compiling for. Therefore=20 if you are compiling for Cortex-A8 (say) and specify -mthumb on the=20 command line it will use both 16-bit and 32-bit Thumb instructions (as=20 they will be available). There is no way to tell GCC to compile for a=20 CPU supporting Thumb-2 but restrict itself to just Thumb-1 instructions. I hope this helps. Thanks, Matt