ARM code extraction utility
Al Borowski
I have written a small Java program that should extract the opcodes out
of a file generated by the ARM SDT (linked to on my webpage). You need
java and the ARM SDT installed to run it. Usage:
1. Make the assembler put 0xFFFFFFFF just before and after your
code. This is done using "DCD 0xFFFFFFFF" on the ARM SDT.
2. Type "java ARM <name of output file from the ARM SDT>". This will
generate a file, output.ARM, containing ARM opcodes formatted to work on
the HP49G+ / MASD.
EG if your code is just MOV PC,LR, alter the assembly file to say
DCD 0xFFFFFFFF ; marker
MOV PC, LR
DCD 0xFFFFFFFF ; end marker
Then run the ARM code extractor to produce a file containing "E00F0A1E",
suitable for putting in MASD.
You can get it at http://alpage.ath.cx/hptute/arm.htm , at the bottom of
the page. Please let me know if there are any bugs, I don't have a 49G+
to test it at the moment. It seems to recreate Cyrille's code fine though.
I'll enhance it tomorrow to also output binary files, suitable for
Thomas Rast's "ARM Loader".
cheers,
Al
Lilian Pigallio
"Al Borowski" <aj.bo...@erasethis.student.qut.edu.au> wrote in message
news:4045c5ce$0$22520$5a62...@freenews.iinet.net.au...
Al Borowski
> Maybe you can "format" you web page with links or chapters....
http://alpage.ath.cx/hptute/arm.htm
better?
Jonathan Busby
<aj.bo...@erasethis.student.qut.edu.au> wrote:
>Hi all,
>
>I have written a small Java program that should extract the opcodes out
>of a file generated by the ARM SDT (linked to on my webpage). You need
>java and the ARM SDT installed to run it. Usage:
There is no need to use any proprietary or specialized software to do
this - the standard *nix/GNU tools work just fine.
First, you'll need the arm-elf build of the GNU binutils installed.
First download the latest version from
http://ftp.gnu.org/gnu/binutils/. Next, get into a unix shell. If
you're under windows, you'll first need to install Cygwin before
proceeding to this step.
(http://www.cygwin.com/) Now, follow the instructions here :
http://www.aleph1.co.uk/armlinux/docs/toolchain/toolchHOWTO/t1.html ,
and build the toolchain to the target "arm-elf" . It only takes three
commands and runs flawlessly under Cygwin.
To assemble an ARM assembly language source file and produce output
useable by the HPTOOLS, do this :
arm-elf-as -mcpu=arm920t -o objectfile sourcefile
arm-elf-objcopy -O binary objectfile objectfile.raw
od -v -An -tx1 -w40 objectfile.raw | sed "s/ //g;s/^/\tNIBHEX\t/"\
> hpinclude.hex
"hpinclude.hex", or whatever you choose to name the final output, is
now suitable for inclusion via the INCLUDE directive into an SASM
source file.
To do disassembly of raw ARM machine code, use :
arm-elf-objdump -b binary -d -m armv5t --prefix-addresses\
--disassemble-zeroes inputfile.raw > disassembly
As you can see, it's very simple.
-------------------------------------------------------------------------------
Jonathan Busby - <j...@SNMAPOhouston.rr.com>
Remove the random permutation of "NOSPAM" from my e-mail address
before replying.
Matt M.
Good work, Jonathan, but I doubt objcopy works if you've got other
symbols. I *do*, however, have a fix for this: use the arm-aout target.
Then, to compile code, you need to:
arm-aout-as -o <objfile> <sourcefile>
arm-aout-ld --oformat binary -o <binfile> <objfile>
Where:
<sourcefile> is the source file (customarily .S),
<objfile> is the object file (customarily .o), and
<binfile> is the binary file (customarily no extension [*nix] or .exe
[Windows])
Since that uses ld, the linker, it *should* work with multiple symbols.
Also, you can still use od, like Mr. Busby said.
Also, you can decompile just as easily with the aout target:
arm-aout-objdump -d -b binary -EL --prefix-addresses input_file >
disassembly
I am keeping an updated copy of a message I posted to this newsgroup
about ARM9 programming with binutils at:
http://paxl.org:2080/~mokomull/binutils-arm9.html
(Mr. Xavier LaRue, please note that this is on *your* server. I am so
very sorry if it gets a slashdot effect.)
-MrM
Jonathan Busby
wrote:
<snip>
> but I doubt objcopy works if you've got other
>symbols.
Don't know what you mean exactly here, but I don't believe the linker
is needed if you're just using local and/or absolute references. But,
it wouldn't hurt.
>I *do*, however, have a fix for this: use the arm-aout target.
<snip>
Why use the ancient a.out format? ELF is a superset of this and is the
most sophisticated and widely used Unix object module format. There's
no extra effort involved in its use. But, it really doesn't matter for
the purposes here what format you use.
I do agree though that it would be a better idea to use ld just to be
on the safe side. Plus, you'll have to use it anyway if you want to
link multiple modules or use some type of "entry points" list. So,
there's really no advantage in using objcopy, since both are just
one-liners .
Matt M.
> On Sat, 06 Mar 2004 09:14:04 -0600, "Matt M." <moko...@yahoo.com>
> wrote:
>>but I doubt objcopy works if you've got other
>>symbols.
>
> Don't know what you mean exactly here, but I don't believe the linker
> is needed if you're just using local and/or absolute references. But,
> it wouldn't hurt.
Symbols are places where it can jump to. If you use objcopy, I doubt
these would be correct, as all it does is copy. However, ld understands
about symbols and linking, so it'll be all right.
>>I *do*, however, have a fix for this: use the arm-aout target.
>
> Why use the ancient a.out format? ELF is a superset of this and is the
> most sophisticated and widely used Unix object module format. There's
> no extra effort involved in its use. But, it really doesn't matter for
> the purposes here what format you use.
Well, if the arm-elf-ld supports "--oformat binary", then it really
doesn't matter. However, I use a.out format because I tried wince-pe
(big mistake), and it didn't support "--oformat binary" (Error: PE
operations on a non-PE file). Since Matthew G. was using the a.out
format (it was precompiled for MSDOS), I gave it a try, and it worked
well. I see no reason to recompile if it's working fine over here. :-)
And you're exactly right: it doesn't matter, if you use objcopy.
> I do agree though that it would be a better idea to use ld just to be
> on the safe side. Plus, you'll have to use it anyway if you want to
> link multiple modules or use some type of "entry points" list. So,
> there's really no advantage in using objcopy, since both are just
> one-liners .
Actually, using objcopy requires three lines -- as -> ld -> objcopy.
Using ld, however, only requires two commands -- as -> ld.
> -------------------------------------------------------------------------------
>
> Jonathan Busby - <j...@SNMAPOhouston.rr.com>
>
> Remove the random permutation of "NOSPAM" from my e-mail address
> before replying.
-MrM
P.S. I do _not_ mean to start a holy war over ELF / a.out here.
Jonathan Busby
wrote:
>> Don't know what you mean exactly here, but I don't believe the linker
>> is needed if you're just using local and/or absolute references. But,
>> it wouldn't hurt.
>
>Symbols are places where it can jump to. If you use objcopy, I doubt
>these would be correct, as all it does is copy. However, ld understands
>about symbols and linking, so it'll be all right.
Well, I'd say it's a little more complicated than that, since a symbol
can be any arbitrary (with some restrictions) name-value pair or
section-offset reference, and it has various associated attributes
such as type, size etc. But, this is all mute as relative local
symbols and absolute symbols are resolved during the assembly process
ie. their referent's are already patched/fixed-up in the output module
and their values are valid relative to their associated section.
>
>>>I *do*, however, have a fix for this: use the arm-aout target.
>>
>> Why use the ancient a.out format? ELF is a superset of this and is the
>> most sophisticated and widely used Unix object module format. There's
>> no extra effort involved in its use. But, it really doesn't matter for
>> the purposes here what format you use.
>
>Well, if the arm-elf-ld supports "--oformat binary", then it really
>doesn't matter.
Well, heh, seems you win here, at least under windoze. ;) The
documentation doesn't indicate any problem but it craps out under
Cygwin.
>> I do agree though that it would be a better idea to use ld just to be
>> on the safe side. Plus, you'll have to use it anyway if you want to
>> link multiple modules or use some type of "entry points" list. So,
>> there's really no advantage in using objcopy, since both are just
>> one-liners .
>
>Actually, using objcopy requires three lines -- as -> ld -> objcopy.
Only if your module contains external or inter-section references.
(and possibly section relative references as well) But, as I stated in
my post, I was talking about when this wasn't the case.
Jonathan Busby
<j...@SNMAPOhouston.rr.com> wrote:
>But, this is all mute <rambling snipped>
Wow, even sentences are starting to talk now. What a crazy world we
live in. (Well, unless you're a schizophrenic, in which case it's
nothing special. ;)
On another note, I hope these guys http://www.cyc.com/ hurry up and
finish before my posts turn into incomprehensible babble. Ooops! Too
late. ;)
Eric Smith
> Symbols are places where it can jump to. If you use objcopy, I doubt
> these would be correct, as all it does is copy. However, ld
> understands about symbols and linking, so it'll be all right.
If the symbols are not external (i.e, they are defined in the source
file), the assembler will emit object code without external references,
thus the linker is not necessary since there is nothing needing to be
linked.
Matt M.
You know what? I was thinking of sections, not symbols =)
Oops.
-MrM