Thanks a lot, I think this explains everything.
Following the disassembled crt0.o, I should save/restore d4-d7 in
PilotMain().
In order to make these registers available to the application, it would
perhaps be a good idea to compile the startup code with -ffixed-d4 etc in
the distribution?
On the other hand, as you pointed out, there can still be several other
(library) routines which don't know anything of my 'dirty tricks'.
I know that I'm doing something exotic and unsafe with my app, but
reservation of 3 or 4 data regs just for the startup routine would be
somewhat wasteful for a 'small device'.
Again, thank you for your help,
--Hans
--
> I suspect the problem is that you are using the global register variable
> functionality without having adequately read its documentation. The
> paragraph I am referring to is:
>
> A function which can alter the value of a global register
> variable cannot safely be called from a function compiled
> without this variable, because it could clobber the value the
> caller expects to find there on return. Therefore, the function
> which is the entry point into the part of the program that uses
> the global register variable must explicitly save and restore
> the value which belongs to its caller.
>
> If you disassemble crt0.o, which was of course "compiled without this
> variable", you'll see that the startup code stores launchFlags in %d4
> and expects it to remain there. Looking additionally at dreloc.c,
> you'll see that if PilotMain() trashes %d4 the effect will be to bypass
> the unlocking of the code resources at application exit.
>
> This is consistent with the symptoms you have described.
>
> John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/