From: Jeffrey Walton <noloader@gmail.com>
To: Matthew Gretton-Dann <matthew.gretton-dann@arm.com>
Cc: GDB Users <gdb@sourceware.org>
Subject: Re: Question on ARM/Thumb-16 Disassembly
Date: Tue, 21 Jun 2011 03:05:00 -0000 [thread overview]
Message-ID: <BANLkTim_jxqwrjuxU3exRqDv0fJZiXk_6Q@mail.gmail.com> (raw)
In-Reply-To: <4DFF71E2.5040402@arm.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
next prev parent reply other threads:[~2011-06-21 3:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-20 15:35 Jeffrey Walton
2011-06-20 16:14 ` Matthew Gretton-Dann
2011-06-21 3:05 ` Jeffrey Walton [this message]
2011-06-21 4:53 ` Jeffrey Walton
2011-06-21 5:01 ` Jeffrey Walton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BANLkTim_jxqwrjuxU3exRqDv0fJZiXk_6Q@mail.gmail.com \
--to=noloader@gmail.com \
--cc=gdb@sourceware.org \
--cc=matthew.gretton-dann@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox