Kevin O'Connor wrote:
> On Sun, Apr 20, 2008 at 12:05:08PM +0100, Oliver Ford wrote:
>
>> Oliver Ford wrote:
>>
>>> It's a little tedious, I'll think of a way of automating some of it if I
>>> can.
>>>
>>>
>> And here's the automation, another patch to apply after the last one:
>> http://www.oliford.co.uk/hpipaq214/haretChanges/0002-MMU-L1-table-merging-output.patch
>>
>>
>
> Hi Oliver,
>
> I'm not sure I fully understand this feature. It looks like you're
> doing a memcmp() against the mmutable and then reporting the change
> tally at the end.
>
That's pretty much it.Theoretically you could do it with the traces
watchlist, but it needs to be a bit faster being that you generally want
to watch as much of the table as possible.
> That said, I don't see any reason not to include this into mainline
> haret. Can you resend a combined patch.
Ok, I'll tidy it up next week some time and send it back. I'll also
write something about how to use it, as I think its something people
might need if they have my version of winCE.
> Please put the mmumerge code into its own file (leaving just the start/stop/trace hooks in
> irq.cpp).
Yes, thats probably more sensible,
> Also, why the name "MMUMerge"?
>
>
The name just arose because it seemed windows has a separate copy of the
MMU table which is switches in/out when running the device driver DLLs
(actually I think it has one for each). The idea was to build one
complete table from the permanent and switched ones (merging them all
into one), which you can then search for register references. If you can
think of a better name I'll happily change it.
Oliver
Received on Wed Apr 30 2008 - 06:29:23 EDT
This archive was generated by hypermail 2.2.0 : Thu May 22 2008 - 07:40:28 EDT