Platform Support Modules
The vtrace platforms package is where the modules live that implement platform specific functionality that is used behind the scenes of the top level Trace object. If you’re not porting vtrace to a new platform, or chasing a bug, you probably don’t need anything from here...
Bases: vtrace.Trace, vtrace.platforms.gdbstub.GdbStubMixin, vtrace.archs.arm.ArmMixin, vtrace.platforms.posix.ElfMixin, vtrace.platforms.base.TracerBase
Tracer Platform Base
Bases: vtrace.notifiers.Notifier
The basis for a tracer’s internals. All platformFoo/archFoo functions are defaulted, and internal state is initialized. Additionally, a number of internal utilities are housed here.
This should be used at load time to setup the library event metadata.
This must be called from a context where it’s safe to fire notifiers, because it will fire a notifier to alert about a LOAD_LIBRARY. (This means not from inside another notifer)
Add a watchpoint for the given address. Raise if the platform doesn’t support, or too many are active...
If the current register state indicates that a watchpoint was hit, return the address of the watchpoint and clear the event. Otherwise return None
This is mostly for systems (like linux) where you can’t tell the difference between some SIGSTOP/SIGBREAK conditions and an actual breakpoint instruction.
This method will return true if either the breakpoint subsystem or the sendBreak (via ShouldBreak meta) is true (and it will have handled firing events for the bp)
Return a list of the stack frames for this process (currently Intel/ebp based only). Each element of the “frames list” consists of another list which is (eip,ebp)
Initialize a mode, this should ONLY be called during setup routines for the trace! It determines the available mode setings.
We are frequently a notifier for ourselves, so we can do things like handle events on attach and on break in a unified fashion.
Actually carry out attaching to a target process. Like platformStepi this is expected to be ATOMIC and not return until a complete attach.
Platform call takes an address, and an array of args (string types will be mapped and located for you)
platformCall is expected to return a dicionary of the current register values at the point where the call has returned...
Platform exec will execute the process specified in cmdline and return the PID
Return a list of the memory maps where each element has the following structure: (address, length, perms, file=””) NOTE: By Default this list is available as Trace.maps because the default implementation attempts to populate them on every break/stop/etc...
Return a dictionary of <threadid>:<tinfo> pairs where tinfo is either the stack top, or the teb for win32
Platforms must parse the given binary file and load any symbols into the internal SymbolResolver using self.addSymbol()
This method processes the event data provided by platformWait()
This method is responsible for firing ALL notifiers except:
vtrace.NOTIFY_CONTINUE - This is handled by the run api (and isn’t the result of an event)
Platform implementers are encouraged to use the metadata field “ThreadId” as the identifier (int) for which thread has “focus”. Additionally, the field “StoppedThreadId” should be used in instances (like win32) where you must specify the ORIGINALLY STOPPED thread-id in the continue.
Set the current signal to deliver to the process on cont. (Use None for no signal delivery.
PlatformStepi should be ATOMIC, meaning it gets called, and by the time it returns, you’re one step further. This is completely regardless of blocking/nonblocking/whatever.
Wait for something interesting to occur and return a platform specific representation of what happened.
This will then be passed to the platformProcessEvent() method which will be responsible for doing things like firing notifiers. Because the platformWait() method needs to be commonly @threadwrap and you can’t fire notifiers from within a threadwrapped function...
Do cleanup when we’re done. This is mostly necissary because of the thread proxy holding a reference to this tracer... We need to let him die off and try to get garbage collected.
A unified place for the test as to weather this trace should be told to run again after reaching some stopping condition.
Bases: threading.Thread
Ok... so here’s the catch... most debug APIs do not allow one thread to do the attach and another to do continue and another to do wait... they just dont. So there. I have to make a thread per-tracer (on most platforms) and proxy requests (for some trace API methods) to it for actual execution. SUCK!
However, this lets async things like GUIs and threaded things like cobra not have to be aware of which one is allowed and not allowed to make particular calls and on what platforms... YAY!
GDB support
For now, the only way I know how to re-break the target is to disconnect and re-connect... TOTALLY GHETTO HACK!
Bases: vtrace.Trace, vtrace.platforms.gdbstub.GdbStubMixin, vtrace.platforms.base.TracerBase
Posix Signaling Module
A mixin for systems which use POSIX signals and things like wait()
A platform mixin for using the ptrace functions to attach/detach/continue/stepi etc. Many *nix systems will probably use this...
NOTE: if you get a PT_FOO undefined, it probably means that the PT_FOO macro isn’t defined for that platform (which means it need to be done another way like PT_GETREGS on darwin doesn’t exist... but the darwin mixin over-rides platformGetRegs)
Solaris Platform Module (Incomplete)
Handle register formats for the intel solaris stuff
Underlying platform implementation for kernel debugging with vmware gdbserver.