Below is something I believe I mentioned recently. This time I just found
the mail and enclose it.
BGK
The technique I use (example is of patching DmOpenDatabase, stripped of
error checking) is:
// My global data.
typedef struct {
various global data
} GlobalsType, *GlobalsPtr;
// Special structure used to create a snippet of code, which gets called
// as the patched routine, sets up the global ptr, and then jumps to the
// real patch code.
typedef struct {
Word opCodes[3];
VoidPtr codeP;
GlobalsPtr globalsP;
} PatchType, *PatchPtr;
// Snippet of patch installation code.
GlobalsPtr gP = (GlobalsPtr)MemPtrNew(sizeof(GlobalsType));
MemPtrSetOwner(gP, 0);
PatchPtr openDBPatch = (PatchPtr)MemPtrNew(sizeof(PatchType));
MemPtrSetOwner(openDBPatch, 0);
// set up code to do move.l *+8,a0 followed by jmp instruction.
openDBPatch->opCodes[0] = 0x207A;
openDBPatch->opCodes[1] = 0x0008;
openDBPatch->opCodes[2] = 0x4EF9;
openDBPatch->globalsP = gP;
openDBPatch->codeP = DmOpenDatabasePatch;
SysSetTrapAddress(sysTrapDmOpenDatabase, openDBPatch);
// DmOpenDatabase patch. This gets called with the pointer to
// globals in register a0.
static DmOpenRef
DmOpenDatabasePatch(UInt cardNo, LocalID dbID, UInt mode)
{
GlobalsPtr gP = GetGlobals();
// do stuff in the patch code.
}
// Return a pointer to our globals. Since they get passed to us in A0,
// and we're returning the GlobalsPtr result in A0, we don't need to
// do anything expect help the compiler generate appropriate code.
static inline asm GlobalsPtr
GetGlobals(void)
{
} // GetGlobals
>An even better approach would be to just allocate the extra needed
>space on the front of your "globals" chunk so you only allocate one
>chunk. This will probably require some clever inline assembly to put
>it all together, but it is possible. Probably would make for a good
>tech note since it solves the issue of having access to globals in
>code that runs at interrupt time.
To do this, you'd put a PatchType record at the beginning of the
GlobalsType record, and do only one allocation - plus the first opcode
would need to change to load the address of the instruction into A0. I had
them separated since I was patching several different traps, all of whom
wanted to share the same global pointer.
-- Ken
-----Original Message-----
From: Todd L. Cignetti <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Thursday, August 19, 1999 12:11 PM
Subject: How to save data from *any* patched API call? (Hack/patch related)
>Greetings,
>
>I understand that some API's should not be patched, but I need to do it
>anyway, for a school project. Let's say I wanted to make an ordered list
of
>every system call that occurred, as it occurred. I could patch every
>individual system call, in HackMaster fashion, to update a log database,
and
>then call the regular system call. More simply, I could replace the trap
15
>handler with a new handler that would log each system call to a database,
>and then jump to the regular trap 15 handler.
>
>The problem is where to store the log? The Feature manager is not
>re-entrant (probably not a good place to write a big log anyway). I would
>guess the database functions are not re-entrant either.
>
>Is there a good way to save this data? Is there any possible way to save
>data from *any* patched API call? Would allocating a big hunk of dynamic
>ram work? (I know it would be rude, possibly even evil, but would it work
>for this toy school project?)
>
>-Todd
>
>
>
>This post was sortof related, so I included it:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Post from 7/23/99:
>At 5:29 PM +0000 1999/07/23, [EMAIL PROTECTED] wrote:
>>Does Palm have a list of which traps should "absolutly not" be trapped ?
>>It would be very helpfull to have something to reference when writting
>>trap code.
>
>They're listed in Appendix A of the Palm OS documentation under the heading
>"System Use Only Functions". Not listed there, however, are all APIs
>beginning with 'Hwr' and 'Prv' which are also very much off-limits.
>
>Also note there may be issues with trap patches installed from HackMaster
>hacks for otherwise seemingly legitimately patchable public APIs, due to
the
>need to call the feature manager from within the trap patch to obtain the
>call-through address.
>
>For example, if the patched API is ever called from within an interrupt
>service routine, system kernel timer, or pre-emptive background thread (to
>name a few). The feature manager is not re-entrant for these cases, so
>FtrGet will eventually crash the device, which could possibly destroy the
>user's data depending on which API had been patched.
>
>This list is obviously incomplete, but it's a start. Hope the info helps!
>
>Regards,
>
>Jim Schram
>3Com/Palm Computing
>Partner Engineering
>
>
>
