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 04:53:00 -0000 [thread overview]
Message-ID: <BANLkTinOCKzrALkoue2B-=f-hwYELdNXfw@mail.gmail.com> (raw)
In-Reply-To: <BANLkTim_jxqwrjuxU3exRqDv0fJZiXk_6Q@mail.gmail.com>
On Mon, Jun 20, 2011 at 11:04 PM, Jeffrey Walton <noloader@gmail.com> wrote:
> 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.
>
> [SNIP]
>
>>
>> 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
>
I came across an ARM sample with the directive "CODE32", which got me
looking for a similar Apple AS directive. I never found the Apple
directives (and as(1) is useless), but I did find Red Hat's at
http://sources.redhat.com/binutils/docs-2.12/as.info/ARM-Directives.html#ARM%20Directives.
So I added a ".code 32" and got the ADDS to assemble:
__asm__ volatile
(
"ldr r4, %[xa] ;" // R4 = a
"ldr r5, %[xb] ;" // R5 = b
".code 32 ;" // same as ".arm"
"adds r6, r4, r5 ;" // R6 = R4 + R5, set status
".code 16 ;" // same as ".thumb"
"bcc 1f ;" // jump if carry is clear
"mov r5, #0 ;" // set overflow
"str r5, %[xc] ;" // write it to memory
"1: ;" // jump target
"str r6, %[xr] ;" // result = R6
: [xr] "=m" (result), [xc] "=m" (no_carry)
: [xa] "m" (a), [xb] "m" (b)
: "r4", "r5", "r6"
);
Unfortunately, EXC_BAD_ACCESS. When I disassemble, 'bcc 1f" is changed
to a "str r5, [r0, #0]" and then a branch into the damn Application
delegate. I've also tried applying ".code 32" to the entire function
(which makes matters worse).
I know I'm missing something (that much is obvious), but I have no
clue what it might be since I've verified the instructions and their
usage against the ARM manual.
Jeff
(gdb) disass
Dump of assembler code for function add_u32:
0x0000232c <add_u32+0>: push {r4, r5, r6, r7, lr}
0x0000232e <add_u32+2>: add r7, sp, #12
0x00002330 <add_u32+4>: sub sp, #20
0x00002332 <add_u32+6>: str r0, [sp, #8]
0x00002334 <add_u32+8>: str r1, [sp, #4]
0x00002336 <add_u32+10>: str r2, [sp, #0]
0x00002338 <add_u32+12>: mov.w r3, #1 ; 0x1
0x0000233c <add_u32+16>: str r3, [sp, #16]
0x0000233e <add_u32+18>: ldr r4, [sp, #8]
0x00002340 <add_u32+20>: ldr r5, [sp, #4]
0x00002342 <add_u32+22>: str r5, [r0, #0]
0x00002344 <add_u32+24>: b.n 0x2470 <-[iDeviceAppDelegate
applicationWillResignActive:]+8>
0x00002346 <add_u32+26>: bcc.n 0x234e <add_u32+34>
0x00002348 <add_u32+28>: mov.w r5, #0 ; 0x0
0x0000234c <add_u32+32>: str r5, [sp, #16]
0x0000234e <add_u32+34>: str r6, [sp, #12]
0x00002350 <add_u32+36>: ldr r3, [sp, #0]
0x00002352 <add_u32+38>: cmp r3, #0
0x00002354 <add_u32+40>: beq.n 0x235c <add_u32+48>
0x00002356 <add_u32+42>: ldr r2, [sp, #12]
0x00002358 <add_u32+44>: ldr r3, [sp, #0]
0x0000235a <add_u32+46>: str r2, [r3, #0]
0x0000235c <add_u32+48>: ldr r3, [sp, #16]
0x0000235e <add_u32+50>: mov r0, r3
0x00002360 <add_u32+52>: sub.w sp, r7, #12 ; 0xc
0x00002364 <add_u32+56>: pop {r4, r5, r6, r7, pc}
End of assembler dump.
next prev parent reply other threads:[~2011-06-21 4:53 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
2011-06-21 4:53 ` Jeffrey Walton [this message]
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='BANLkTinOCKzrALkoue2B-=f-hwYELdNXfw@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