From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23793 invoked by alias); 21 Jun 2011 04:53:30 -0000 Received: (qmail 23785 invoked by uid 22791); 21 Jun 2011 04:53:29 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST 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 04:53:12 +0000 Received: by wyg36 with SMTP id 36so1105201wyg.0 for ; Mon, 20 Jun 2011 21:53:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.235.158 with SMTP id u30mr5563889weq.104.1308631990968; Mon, 20 Jun 2011 21:53:10 -0700 (PDT) Received: by 10.216.87.202 with HTTP; Mon, 20 Jun 2011 21:53:10 -0700 (PDT) Reply-To: noloader@gmail.com In-Reply-To: References: <4DFF71E2.5040402@arm.com> Date: Tue, 21 Jun 2011 04:53: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/msg00132.txt.bz2 On Mon, Jun 20, 2011 at 11:04 PM, Jeffrey Walton wrote: > 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 = make >> below are based upon the behaviour of the vanilla FSF tools, Apple may h= ave >> changed their behaviors in ways I am unaware of. > > [SNIP] > >> >> 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 semantic= s 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 = does >> 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 =A0 r6, r5, r4 =A0 =A0 =A0;" =A0 =A0 =A0// R6 =3D R5 + R4, sets car= ry > "adds =A0 r5, r4 =A0 =A0 =A0 =A0 =A0;" =A0 =A0 =A0// R5 +=3D R4, sets car= ry > > 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 =A0 =A0 =A0;" =A0 =A0 =A0// R6 =3D R5 + R4, sets carry > "adds.w r5, r4 =A0 =A0 =A0 =A0 =A0;" =A0 =A0 =A0// R5 +=3D 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#AR= M%20Directives. So I added a ".code 32" and got the ADDS to assemble: __asm__ volatile ( "ldr r4, %[xa] ;" // R4 =3D a "ldr r5, %[xb] ;" // R5 =3D b ".code 32 ;" // same as ".arm" "adds r6, r4, r5 ;" // R6 =3D 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 =3D R6 : [xr] "=3Dm" (result), [xc] "=3Dm" (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 : push {r4, r5, r6, r7, lr} 0x0000232e : add r7, sp, #12 0x00002330 : sub sp, #20 0x00002332 : str r0, [sp, #8] 0x00002334 : str r1, [sp, #4] 0x00002336 : str r2, [sp, #0] 0x00002338 : mov.w r3, #1 ; 0x1 0x0000233c : str r3, [sp, #16] 0x0000233e : ldr r4, [sp, #8] 0x00002340 : ldr r5, [sp, #4] 0x00002342 : str r5, [r0, #0] 0x00002344 : b.n 0x2470 <-[iDeviceAppDelegate applicationWillResignActive:]+8> 0x00002346 : bcc.n 0x234e 0x00002348 : mov.w r5, #0 ; 0x0 0x0000234c : str r5, [sp, #16] 0x0000234e : str r6, [sp, #12] 0x00002350 : ldr r3, [sp, #0] 0x00002352 : cmp r3, #0 0x00002354 : beq.n 0x235c 0x00002356 : ldr r2, [sp, #12] 0x00002358 : ldr r3, [sp, #0] 0x0000235a : str r2, [r3, #0] 0x0000235c : ldr r3, [sp, #16] 0x0000235e : mov r0, r3 0x00002360 : sub.w sp, r7, #12 ; 0xc 0x00002364 : pop {r4, r5, r6, r7, pc} End of assembler dump.