> This is what I'd try to do....
>
> As long as the file streaming API as well as the DB API come to allocating
> memory, you'll always be limited to the available system memory.
> If you allocate a fixed buffer and the simply write to it (while in trap,
> using the suggested approach), you'll be limited by the size of the
> allocated block.
> If you want to make that block extendable (again, up to the memory
limits),
> you couldn't use the DB api for the reasons already discussed, but I'd
> assume (and check several times!!!) that you could use MemPtrNew. If you
> can't - then I'd simply forget the idea. If you can, though, you'd be able
> to create a linked list of memory blocks, which is a primitive, but yet
> functional DB structure.
> Will that work for you?
My guess is MemPtrNew is not safe, (how can I find out?). What if I
allocate a big chunk of RAM at the start, write the log information to it
from the trap handler, and when it's nearly full, signal the application
with an event (EvtEnqueueKey - is interrupt safe) to write out the queue to
a database.
The reason I can't use POSE is due to the second part of the project, which
is to correllate this information with power consumption, which the emulator
can't do (yet).
>
>
> BTW, if you want to catch _all_ systraps....you need to get the interrupt
> handler, probably, which dispatches the interrupt call. Is that what you
> plan to do?
How does the the PalmOS dispatch interrupts?
>
> BGK
> -----Original Message-----
> From: Todd L. Cignetti <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Date: Thursday, August 19, 1999 3:18 PM
> Subject: Re: How to save data from *any* patched API call? (Hack/patch
> related)
>
>
> >The maximum size of the log would be limited to the size of RAM with this
> >solution.
> >Is there a way to do this with a database or the file streaming API?
> >
> >----- Original Message -----
> >From: Bobby Kolev <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Sent: Thursday, August 19, 1999 1:44 PM
> >Subject: Re: How to save data from *any* patched API call? (Hack/patch
> >related)
> >
> >
> >> 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
> >> >
> >> >
> >> >
> >>
> >>
> >
>
>
