From: Jeffrey Walton <noloader@gmail.com>
To: GDB Users <gdb@sourceware.org>
Subject: Question on ARM/Thumb-16 Disassembly
Date: Mon, 20 Jun 2011 15:35:00 -0000 [thread overview]
Message-ID: <BANLkTikATazyeKYowM451mZCRFTRf4o_3g@mail.gmail.com> (raw)
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.
next reply other threads:[~2011-06-20 15:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-20 15:35 Jeffrey Walton [this message]
2011-06-20 16:14 ` Matthew Gretton-Dann
2011-06-21 3:05 ` Jeffrey Walton
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=BANLkTikATazyeKYowM451mZCRFTRf4o_3g@mail.gmail.com \
--to=noloader@gmail.com \
--cc=gdb@sourceware.org \
/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