From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5788 invoked by alias); 21 Jun 2011 03:05:15 -0000 Received: (qmail 5780 invoked by uid 22791); 21 Jun 2011 03:05:14 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,TW_GD X-Spam-Check-By: sourceware.org Received: from mail-wy0-f169.google.com (HELO mail-wy0-f169.google.com) (74.125.82.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 21 Jun 2011 03:05:00 +0000 Received: by wyg36 with SMTP id 36so1065132wyg.0 for ; Mon, 20 Jun 2011 20:04:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.133.87 with SMTP id p65mr196441wei.74.1308625498523; Mon, 20 Jun 2011 20:04:58 -0700 (PDT) Received: by 10.216.87.202 with HTTP; Mon, 20 Jun 2011 20:04:58 -0700 (PDT) Reply-To: noloader@gmail.com In-Reply-To: <4DFF71E2.5040402@arm.com> References: <4DFF71E2.5040402@arm.com> Date: Tue, 21 Jun 2011 03:05:00 -0000 Message-ID: Subject: Re: Question on ARM/Thumb-16 Disassembly From: Jeffrey Walton To: Matthew Gretton-Dann Cc: GDB Users Content-Type: text/plain; charset=ISO-8859-1 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/msg00127.txt.bz2 On Mon, Jun 20, 2011 at 12:14 PM, Matthew Gretton-Dann wrote: > On 20/06/11 16:35, Jeffrey Walton wrote: >> A couple of questions for ARM/Thumb-2. I'm working on a live iPhone, >> so I'm using Apple's GAS. My bad: Thumb-16. > It would be useful if you could give the command line you are using - as I > can't give precise answers without that info. =A0Most of the comments I m= ake > below are based upon the behaviour of the vanilla FSF tools, Apple may ha= ve > changed their behaviors in ways I am unaware of. /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -x c -arch armv6 -fmessage-length=3D0 -pipe -std=3Dc99 -Wno-trigraphs -fpascal-strings -O0 -Wreturn-type -Wunused-variable -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk -fvisibility=3Dhidden -gdwarf-2 -mthumb -miphoneos-version-min=3D3.2 -iquote /Users/jeffrey/Desktop/intoverflow/build/iDevice.build/Debug-iphone= os/iDevice.build/iDevice-generated-files.hmap -I/Users/jeffrey/Desktop/intoverflow/build/iDevice.build/Debug-iphoneos/iDe= vice.build/iDevice-own-target-headers.hmap -I/Users/jeffrey/Desktop/intoverflow/build/iDevice.build/Debug-iphoneos/iDe= vice.build/iDevice-all-target-headers.hmap -iquote /Users/jeffrey/Desktop/intoverflow/build/iDevice.build/Debug-iphone= os/iDevice.build/iDevice-project-headers.hmap -F/Users/jeffrey/Desktop/intoverflow/build/Debug-iphoneos -I/Users/jeffrey/Desktop/intoverflow/build/Debug-iphoneos/include -I/Users/jeffrey/Desktop/intoverflow/build/iDevice.build/Debug-iphoneos/iDe= vice.build/DerivedSources/armv6 -I/Users/jeffrey/Desktop/intoverflow/build/iDevice.build/Debug-iphoneos/iDe= vice.build/DerivedSources -include /var/folders/dC/dCfs8ij4HeWN-ZqbDcAWyU+++TI/-Caches-/com.apple.Xco= de.501/SharedPrecompiledHeaders/iDevice-Prefix-fqqgplseposzlsgjezeqayjmdnny= /iDevice-Prefix.pch -c /Users/jeffrey/Desktop/intoverflow/intoverflow-add.c -o /Users/jeffrey/Desktop/intoverflow/build/iDevice.build/Debug-iphoneos/iDevi= ce.build/Objects-normal/armv6/intoverflow-add.o For completeness: $ /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/as -v Apple Inc version cctools-797~183, GNU assembler version 1.38 And in Xcode 3.2.6, "Compile for thumb" is checked (its the default setting). Note that vanilla ARM (ie, unchecking) works/assembles fine. Also, ARM6 is selected. >> 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: > > =A01. 'divided' syntax - where add instruction has different semantics > depending on whether you are in Thumb or ARM state. > =A02. 'unified' syntax - where the add instruction has the same semantics= in > ARM and Thumb state. Not sure about this - its inline assembly. > (Look for a .syntax directive in your assembly source). > > My guess is that you have written something like the following in your > assembly code: > =A0 add r0, r1, r2 Yes. > Which would set the flags in Thumb-1 code when using divided syntax but d= oes > not when using unified syntax. > > So the fix is to do the following instead: > =A0 adds r0, r1, r2 > > [The additional 's' means set the flags]. OK - got that. Neither of the following will assemble, so I moved to the non-condition updating ADD. "adds r6, r5, r4 ;" // R6 =3D R5 + R4, sets carry "adds r5, r4 ;" // R5 +=3D R4, sets carry Both result in: {standard input}:262:instruction not supported in Thumb16 mode -- `adds r6,r5,r4' For S&G, I also tried the following to try and generate the 32 bit (wide) instructions: "adds.w r6, r5, r4 ;" // R6 =3D R5 + R4, sets carry "adds.w r5, r4 ;" // R5 +=3D R4, sets carry >> (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 instruction > set for the CPU/architecture it is compiling for. =A0Therefore if you are > compiling for Cortex-A8 (say) and specify -mthumb on the command line it > will use both 16-bit and 32-bit Thumb instructions (as they will be > available). =A0There is no way to tell GCC to compile for a CPU supporting > Thumb-2 but restrict itself to just Thumb-1 instructions. According to the ARM reference, when operating in Thumb mode, the condition flags are set. I'm reading that ADD wil set the condition flag, with no need for ADDS and friends. See 'ARM=AE Developer Suite, v1.2', Section 2.2.8, page 2-9: The conditional branch instruction is the only Thumb instruction that can be executed conditionally on the value of the ALU status flags in the CPSR. All data processing instructions update these flags, except when one or more high registers are specified as operands to the MOV or ADD instructions. In these cases the flags cannot be updated. Thanks for the help Matt. I'm missing something, but its not jumping out at= me. Jeff