Benoit Cerrina wrote:
Hi David,
I am more or less in the same situation as you, if you do manage to
compile your app for arm, can you send the list (or just me) a
description of the hoops you had to jump through,
I always postponed doing it but some parts of my apps could really benefit.
Whoo boy, hoops. So, I finally managed to get my app running entirely in ARM mode. Here is
basically what I did:
1. I updated my makefile to compile and link everything using the arm-palmos toolchain as
well as the m68k-palmos toolchain. My compiler command line looks like:
arm-palmos-g++ -g -W -Wall -Wpointer-arith -fshort-enums -funroll-loops -fPIC
-march=armv4t -msingle-pic-base -mpic-register=r10 -fno-rtti -fno-exceptions
-fconserve-space -c src/Application.cc -o work/arm/Application.o
linking looks something like:
arm-palmos-g++ -g -Wl,--emit-relocs -Wl,--split-by-file=64000 -nostartfiles -nostdlib -W
-Wall -Wpointer-arith -t armlink.ld -o work/myapp.arm work/arm/*.o -lgcc
2. All the PalmOS system calls gave link errors because you can't just call them directly
from ARM mode. I wrote a compatibility layer to satisfy all the unresolved link errors for
the system calls. This is basically an implementation of all the system calls you
reference that wraps the real system call. Aaron Ardiri posted some instructions about how
to do this a while back on PNO-forum, which is what I based mine on.
3. When I tried to call the arm-palmos linker, it complained that it could not find -lm,
even though I did not specify it. So I specified -nostdlib and -lgcc. That got the
_umodsi3 and _divsi3 references, but it still couldn't find memcpy or memset, both calls
automatically generated by the compiler. I had implementations lying around for those, so
I just stuffed them in myself.
4. If you have any templates or inline functions in your code, g++ will put each
template/inlined function into it's own uniquely-named code segment. This is how the
linker eliminates duplicate object code at link time. PEAL ended up deciding to put each
of these into a different 'armc' code resource. So I modified the link script to include
all .gnu.linkonce.t* sections into the .text section and the .gnu.linkonce.d* sections
into the data section. I just posted the link script today in the palm pno-forum for
anyone that needs it.
At this point my code compiled, but the phone hung when running the app.
5. I wrote a couple simple logging functions that used the VFS to write a log file to the
memory card. When the app crashed, I stuck the memory card into my reader and looked at
the log. This was an immense help to me for track down problems.
6. I had to move my entry point function inside an extern "C" block, so that C++ wouldn't
mangle the name and Peal's symbol lookup facility wouldn't fail.
7. Peal also has this to say:
WARNING: ignoring R_ARM_PLT32 relocation (symbol '__div0')
The program works despite this, even though I don't really know what it means. So I just
ignored this.
8. I am using several Glue functions, which are not system traps, but actualy 68k compiled
functions. There is no ARM Glue lib as far as I know, so I had to collect the function
pointers of all the Glue functions I wanted into a table, then pass that table into my ARM
entry-point function. The ARM function then set the table into a global variable, and I
had wrappers for the glue functions that forwarded the call to the m68k function pointers
in the table. There are examples of this in the PalmOS ARM documentation. One tricky thing
was that the macro I was using to call the system traps passed the trap through
PceNativeTrapNo() before sending it to gCall68KFuncP. When I passed the M68K function
pointers to the same macro, they didn't work, because you can't call PceNativeTrapNo() on
the function pointers... That took me FOREVER to notice - probably mostly because I
copied the macros off of posted source code in this newsgroup.
9. I reimplmented SysInsertionSort from scratch, so that you could pass in an ARM
comparator function in the ARM side and have it work. I didn't want to have to get another
silly function pointer that was really specific to my application over into the M68K
function pointer table.
10. I also had problems with StrPrintF until I realized that, since varargs sort of bites
and doesn't tell you the size or number of parameters, there's no way to correct
endianness for the varargs parameter list automatically - so I wrap all the arguments with
a byte-swapping macro that does nothing in m68k, but does the endian switch in ARM. You
just get wrong numbers for numbers, but if you pass a string in there and don't get the
endianness right, the app will crash.
I don't know if I'm doing things stupidly, or if PRC-tools is just not supported well
enough, but this was basically a nightmare. I only hope that by giving this lengthy
accounting, other poor souls will save some time and sanity.
But, heh, it should be relatively smooth sailing from here... right?
-DG
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
