Currently, our instrumenter contains no data as to what original DLL it
corresponds to. A small data section containing some identifying information
should be added as part of the instrumenting process. Similarly, the generated
call-trace ETW file is not sufficient on its own to parse events. We currently
need to correlate it with kernel events in order to determine in what module
the events originate. Each instrumented module should output an event at load
time that indicates the instrumented and original modules that the events
correspond to (maybe an unload event as well?). This will also greatly simplify
processing for orderings that will require data from multiple profiling runs
(no need to correlate multiple call-trace files to multiple kernel trace files).
The order generator should similarly output identifying information for the
original module that is meant to be applied to. Finally, the relinker should
validate this information before actually relinking a module.
Original issue reported on code.google.com by chri...@chromium.org on 16 Jun 2011 at 1:21
Original issue reported on code.google.com by
chri...@chromium.org
on 16 Jun 2011 at 1:21