From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-39400-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 25899 invoked by alias); 20 Jun 2011 15:35:35 -0000
Received: (qmail 25765 invoked by uid 22791); 20 Jun 2011 15:35:33 -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
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; Mon, 20 Jun 2011 15:35:19 +0000
Received: by wyg36 with SMTP id 36so648227wyg.0        for <gdb@sourceware.org>; Mon, 20 Jun 2011 08:35:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.217.4.76 with SMTP id t54mr4935420wes.96.1308584118256; Mon, 20 Jun 2011 08:35:18 -0700 (PDT)
Received: by 10.216.87.202 with HTTP; Mon, 20 Jun 2011 08:35:18 -0700 (PDT)
Reply-To: noloader@gmail.com
Date: Mon, 20 Jun 2011 15:35:00 -0000
Message-ID: <BANLkTikATazyeKYowM451mZCRFTRf4o_3g@mail.gmail.com>
Subject: Question on ARM/Thumb-16 Disassembly
From: Jeffrey Walton <noloader@gmail.com>
To: GDB Users <gdb@sourceware.org>
Content-Type: text/plain; charset=ISO-8859-1
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2011-06/txt/msg00119.txt.bz2

Hi All,

A couple of questions for ARM/Thumb-2. I'm working on a live iPhone,
so I'm using Apple's GAS.

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).

(2) Are 4 byte instructions expected when GCC generates Thumb-16 code?
The ARM Instruction Reference seems to state otherwise.

Jeff

(gdb) disassemble
Dump of assembler code for function add_u32:
0x00002328 <add_u32+0>:	push	{r4, r5, r6, r7, lr}
0x0000232a <add_u32+2>:	add	r7, sp, #12
0x0000232c <add_u32+4>:	sub	sp, #20
0x0000232e <add_u32+6>:	str	r0, [sp, #8]
0x00002330 <add_u32+8>:	str	r1, [sp, #4]
0x00002332 <add_u32+10>:	str	r2, [sp, #0]
0x00002334 <add_u32+12>:	mov.w	r3, #1	; 0x1
0x00002338 <add_u32+16>:	str	r3, [sp, #16]
0x0000233a <add_u32+18>:	mov.w	r3, #0	; 0x0
0x0000233e <add_u32+22>:	str	r3, [sp, #12]
0x00002340 <add_u32+24>:	ldr	r4, [sp, #8]
0x00002342 <add_u32+26>:	ldr	r5, [sp, #4]
0x00002344 <add_u32+28>:	add	r5, r4
0x00002346 <add_u32+30>:	bcc.n	0x234e <add_u32+38>
0x00002348 <add_u32+32>:	mov.w	r6, #0	; 0x0
0x0000234c <add_u32+36>:	str	r6, [sp, #16]
0x0000234e <add_u32+38>:	str	r5, [sp, #12]
0x00002350 <add_u32+40>:	ldr	r3, [sp, #0]
0x00002352 <add_u32+42>:	cmp	r3, #0
0x00002354 <add_u32+44>:	beq.n	0x235c <add_u32+52>
0x00002356 <add_u32+46>:	ldr	r2, [sp, #12]
0x00002358 <add_u32+48>:	ldr	r3, [sp, #0]
0x0000235a <add_u32+50>:	str	r2, [r3, #0]
0x0000235c <add_u32+52>:	ldr	r3, [sp, #16]
0x0000235e <add_u32+54>:	mov	r0, r3
0x00002360 <add_u32+56>:	sub.w	sp, r7, #12	; 0xc
0x00002364 <add_u32+60>:	pop	{r4, r5, r6, r7, pc}
End of assembler dump.