<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">That depends on how you define "one ARM instruction." It's not a clear cut thing. For example, is "add r1, r2, r3" the same ARM instruction as "add r1, r2, #4"? What is a distinct instruction and what's a variant encoding of the same instruction is often entirely a matter of convenience.<div><br></div><div>-Jim<br><div><br></div><div><br><div><div>On Jun 8, 2012, at 6:40 AM, Fan Dawei <<a href="mailto:fandawei.s@gmail.com">fandawei.s@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi Jim,<br><br>Thanks for reply. I'm sorry I didn't make myself clear enough. <br><br>The MCInst created by MCDisassembler depends on the instructions defined in td files. These instructions do not have a one to one mapping to ARM instructions. There are usually one or more instructions defined in the td file correspond to one actual ARM instruction.<br>
<br>Thanks,<br>David<br><br><div class="gmail_quote">On Thu, Jun 7, 2012 at 1:27 PM, Jim Grosbach <span dir="ltr"><<a href="mailto:grosbach@apple.com" target="_blank">grosbach@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div class="im"><div>On Jun 7, 2012, at 7:53 AM, Fan Dawei <<a href="mailto:fandawei.s@gmail.com" target="_blank">fandawei.s@gmail.com</a>> wrote:</div><br><blockquote type="cite">
Hi Tim,<div><br></div><div>Thanks a lot for your help! I'm very grateful.</div><div><br></div><div>libc.so is a prelinked library, I'll build a non-prelinked one and have another try.</div><div><br></div><div>I'm now at the start of a binary translation project. I want to convert ARM binary code [*] to llvm ir, which is then translated to binary for our mips like architecture. That's why I'm looking for a decoder for ARM binary. </div>
<div><br></div><div>The ARMMCDisassembler is production quality as be told by Evan. That's why I'm so interested in it. However, I realized today that might not be a good choice. Although the disassembled MCInsts has a clean and simple interface, the op-codes in them are auto generated from instruction description files. They are in large quantities and do not have one-to-one correspondence to arm instructions. I think it is not a good idea for our translator to rely on the implementation of llvm ARM back-end. So I have to find another decoder or implement it by by ourselves.</div>
</blockquote><div><br></div></div><div>Every MCInst created by the MCDisassembler will have a one-to-one mapping to an actual ARM instruction.</div><br><blockquote type="cite"><div><div class="h5">
<div><br></div><div><div>Thanks,</div><div>David</div></div><div><br></div><div>[*] For most case, the targets are the shared libraries in Android APKs developed by NDK, like libangraybird.so. I think most of them are pre-linked, so it is bad for us. Because there is no $a, $t and $d symbols, we cannot figure out which region is arm code or thumb code statically.</div>
<div><br></div><div><br><div class="gmail_quote">On Thu, Jun 7, 2012 at 8:11 PM, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi David,<br>
<div><br>
On Thu, Jun 7, 2012 at 10:17 AM, Fan Dawei <<a href="mailto:fandawei.s@gmail.com" target="_blank">fandawei.s@gmail.com</a>> wrote:<br>
> Could you please tell me more about $a, $t and $d symbols? How these symbols<br>
> are used to define different regions? Where I can find this symbols in ELF<br>
> object file?<br>
<br>
</div>At the start of each range of ARM code, an assembler or compiler<br>
should produce a "$a" symbol with that address, and put it (naturally<br>
enough) in the ELF symbol-table. Similarly each stretch of Thumb code<br>
gets a "$t" and each data a "$d".<br>
<br>
For example if I assemble:<br>
<br>
.arm<br>
mov r0, r3<br>
ldr r2, Lit<br>
Lit:<br>
.word 42<br>
add r0, r0, r0<br>
.thumb<br>
mov r5, r2<br>
<br>
then the symbol table contains these entries:<br>
4: 00000000 0 NOTYPE LOCAL DEFAULT 1 $a<br>
[...]<br>
6: 00000008 0 NOTYPE LOCAL DEFAULT 1 $d<br>
7: 0000000c 0 NOTYPE LOCAL DEFAULT 1 $a<br>
8: 00000010 0 NOTYPE LOCAL DEFAULT 1 $t<br>
<br>
which shows that an ARM region begins at offset 0x0, a data one at<br>
offset 0x8, we switch back to ARM at 0xc and finally Thumb takes over<br>
at 0x10.<br>
<br>
GNU objdump hides the symbols by default when printing the<br>
symbol-table (you can give it the --special-syms option to show them),<br>
but readelf shows them always.<br>
<br>
If you want the really deep details, they're fully documented in the<br>
ARM ELF ABI here (section 4.6.5):<br>
<br>
<a href="http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044d/IHI0044D_aaelf.pdf" target="_blank">http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044d/IHI0044D_aaelf.pdf</a><br>
<br>
Which is all nice to know, but I'm afraid it probably doesn't offer an<br>
immediate solution to the undefined instructions:<br>
+ libc.so isn't a relocatable object file (well, it is dynamically,<br>
but that doesn't count).<br>
+ llvm-objdump ignores them anyway at the moment, as far as I can tell.<br>
<span><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div></div></div><div class="im">
_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></div></blockquote></div><br></div>
</blockquote></div><br>
</blockquote></div><br></div></div></body></html>