Ben,
Your code resource starts off with a string of text. I've spent enough time
reading backwards text in little-endian versions of Poser (yes, all 16-bit
values are byteswapped to help performance) that I may be able to make a stab at
this:
"Error from DmDatabaseInfo<null>code03e9.c"
After that appears your function. I'm not sure why that string's there, but I
would have expected the function to be the first thing (right after the 0000
0001).
Another thing that's odd is that the values are byteswapped in the .bin file. I
would have expected to only see them byteswapped in xcopilot's memory. On disk
(at least, in the .prc file), everything should be in BigEndian format.
-- Keith
Ben Darnell <[EMAIL PROTECTED]> on 09/22/99 06:03:06 PM
Please respond to [EMAIL PROTECTED]
Sent by: Ben Darnell <[EMAIL PROTECTED]>
To: "'palm-dev-forum @3com.com'" <[EMAIL PROTECTED]>
cc: (Keith Rollin/HQ/3Com)
Subject: Illegal instruction: 4275
I am writing a Hack that causes xcopilot to give an error message
"Illegal instruction: 4275" whenever its code is executed. (The same
hack run on a device gives a Fatal Exception dialog. When run on POSE,
it just sits there (same symptoms as if an app were stuck in an infinite
loop)). There are two traps in this hack, but only one has this
problem. I am trapping SysUIAppSwitch.
I use gcc on Linux (prc-tools-0.5.0r-3 from the Debian distribution).
%m68k-palmos-coff-gcc -v
Reading specs from /usr/lib/gcc-lib/m68k-palmos-coff/2.7.2.2-kgpd-071097/specs
gcc version 2.7.2.2-kgpd-071097
This is the compilation statement from my Makefile:
$(CC) $(CFLAGS) -nostartfiles -o $(*F) $<
After variable expansion:
m68k-palmos-coff-gcc -g -Wall -O2 -nostartfiles -o code03e9
code03e9.c
Here are the contents of the code resource in question:
%hexdump code03e9.bin | head
0000000 0000 0100 7245 6f72 2072 7266 6d6f 4420
0000010 446d 7461 6261 7361 4965 666e 006f 6f63
0000020 6564 3330 3965 632e 0000 564e c4ff e748
0000030 3018 2e38 0800 2e26 0a00 7c3d 0e00 caff
0000040 6e48 ccff 3c3f e903 3c2f 4d4c 4848 4f4e
0000050 7ba2 6e26 ccff 3c1f 0100 6e48 caff 6e48
0000060 d0ff 6742 3c2f 4d4c 4848 4f4e d3a2 fcde
0000070 1a00 404a 066e 7c1d 0100 dcff 2e4a dcff
0000080 5867 6e48 c6ff a742 a742 a742 a742 a742
0000090 a742 a742 a742 a742 ee45 deff 0a2f 032f
The pattern 4572 does not appear in the file, but 7245 is there in bytes
5 and 6. This is apparently getting byte-swapped somewhere along the
way; I assume that is correct behavior, since I can compile and run
other things successfully.
Here's part of the assembly generated by the compiler (by using the above
command line with the -S parameter):
---------------------------------------------------------------------
.globl SysUIAppSwitchHandler
SysUIAppSwitchHandler:
.def .bf; .val .; .scl 101; .line 29;
.endef
.def cardno; .val 8; .scl 9; .type 015;
.endef
.def dbid; .val 10; .scl 9; .type 017;
.endef
.def cmd; .val 14; .scl 9; .type 015;
.endef
.def cmdPBP; .val 16; .scl 9; .type 022;
.endef
.def cardno; .val 4; .scl 4; .type 015;
.endef
.def dbid; .val 3; .scl 4; .type 017;
.endef
link.w %a6,#-60
movm.l #0x1830,-(%sp)
move.w 8(%a6),%d4
move.l 10(%a6),%d3
.ln 2
.def temp; .val -52; .scl 1; .type 017;
.endef
.def oldTrap; .val 11; .scl 4; .type
0223;
.endef
.def creator; .val -58; .scl 1; .type
017;
.endef
.def name; .val -34; .scl 1; .dim 33;
.size
33; .type 062; .endef
.def prefs; .val -48; .scl 1; .tag .96fake;
.size 14; .type 010; .endef
.def prefssize; .val -54; .scl 1; .type
015;
.endef
.ln 8
move.w #14,-54(%a6)
.ln 12
pea -52(%a6)
move.w #1001,-(%sp)
move.l #1280133192,-(%sp)
trap #15; dc.w 0xa27b
-------------------------------------------------------------------
That goes from the beginning of the first function in the .c file to the
first executable statment (FtrGet())
The C code that produced that assembly (if it would help to see the
entire file, just ask):
---------------------------------------------------------------------
Err SysUIAppSwitchHandler(UInt cardno, LocalID dbid, Word cmd, Ptr
cmdPBP)
{
DWord temp;
Err (*oldTrap)(UInt,LocalID,Word,Ptr);
ULong creator;
Char name[33];
MyPrefsType prefs;
Word prefssize=sizeof(prefs);
SWord prefsver;
Err err;
FtrGet(MYCRID, 0x3e9, &temp);
oldTrap=(Err(*)(UInt,LocalID,Word,Ptr))temp;
----------------------------------------------------------------------
Does anyone have any suggestions as to what may be causing this? I've
included the assembly and hex dumps on the chance that it's a compiler
bug, although I realize that a bug in my own code is far more likely.
Thanks,
-Ben
--
Ben Darnell [EMAIL PROTECTED]
http://www4.ncsu.edu/~bgdarnel/thoughtstream/