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/







Reply via email to