This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Question on ARM/Thumb-16 Disassembly
- From: Jeffrey Walton <noloader at gmail dot com>
- To: Matthew Gretton-Dann <matthew dot gretton-dann at arm dot com>
- Cc: GDB Users <gdb at sourceware dot org>
- Date: Mon, 20 Jun 2011 23:04:58 -0400
- Subject: Re: Question on ARM/Thumb-16 Disassembly
- References: <BANLkTikATazyeKYowM451mZCRFTRf4o_3g@mail.gmail.com> <4DFF71E2.5040402@arm.com>
- Reply-to: noloader at gmail dot com
On Mon, Jun 20, 2011 at 12:14 PM, Matthew Gretton-Dann
<matthew.gretton-dann@arm.com> 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. ?Most of the comments I make
> below are based upon the behaviour of the vanilla FSF tools, Apple may have
> 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=0 -pipe -std=c99 -Wno-trigraphs
-fpascal-strings -O0 -Wreturn-type -Wunused-variable -isysroot
/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk
-fvisibility=hidden -gdwarf-2 -mthumb -miphoneos-version-min=3.2
-iquote /Users/jeffrey/Desktop/intoverflow/build/iDevice.build/Debug-iphoneos/iDevice.build/iDevice-generated-files.hmap
-I/Users/jeffrey/Desktop/intoverflow/build/iDevice.build/Debug-iphoneos/iDevice.build/iDevice-own-target-headers.hmap
-I/Users/jeffrey/Desktop/intoverflow/build/iDevice.build/Debug-iphoneos/iDevice.build/iDevice-all-target-headers.hmap
-iquote /Users/jeffrey/Desktop/intoverflow/build/iDevice.build/Debug-iphoneos/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/iDevice.build/DerivedSources/armv6
-I/Users/jeffrey/Desktop/intoverflow/build/iDevice.build/Debug-iphoneos/iDevice.build/DerivedSources
-include /var/folders/dC/dCfs8ij4HeWN-ZqbDcAWyU+++TI/-Caches-/com.apple.Xcode.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/iDevice.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 = 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
> depending on whether you are in Thumb or ARM state.
> ?2. '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:
> ? add r0, r1, r2
Yes.
> Which would set the flags in Thumb-1 code when using divided syntax but 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].
OK - got that. Neither of the following will assemble, so I moved to
the non-condition updating ADD.
"adds r6, r5, r4 ;" // R6 = R5 + R4, sets carry
"adds r5, r4 ;" // R5 += 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 = R5 + R4, sets carry
"adds.w r5, r4 ;" // R5 += 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. ?Therefore 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). ?There 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® 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