This is the mail archive of the
mailing list for the frysk project.
Re: Adding breakpoints
- From: Andrew Cagney <cagney at redhat dot com>
- To: Mark Wielaard <mark at klomp dot org>
- Cc: frysk at sources dot redhat dot com
- Date: Wed, 05 Jul 2006 00:33:53 -0400
- Subject: Re: Adding breakpoints
- References: <email@example.com>
Mark Wielaard wrote:
Hi,you mean for frysk? anything involving the core gets routed through the
event-loop and its thread (which is also responsible for juggling kernel
events). This is why there's a public Task.requestBLAH that injects an
event to call Task.handleBLAH from the event-loop.
I was playing with adding (low-level) breakpoint support to Tasks and
came up with the following setup. We add a BreakpointAddresses class
which keeps track of the actual breakpoints needed (one address can have
multiple observers). The Task uses this BreakpointAddresses class to
notify the observers when it traps a breakpoint. The BreakpointAddresses
class interacts with the Task to actually set and remove the breakpoints
when needed, and tells the Task when it needs to start or when it can
stop tracing breakpoints (because none are left). When a breakpoint is
added or removed in a state that doesn't immediately allow
setting/removing a breakpoint (normally that can only be done when the
Task is in an suspended state) then the BreakpointAddresses class lets
the Task know it has updates of the breakpoints list and gets called by
the Task as soon as it enters a TaskState that allows addition/removal
of breakpoints. An draft of the BreakpointAddresses class and the
methods it uses is attached.
Some open questions on which I hope to get answers when implementing the
rest (or maybe someone already has ideas on these):
- What is the precise thread model used? The data-structures of this
class are thread safe, but that might be overkill if observers are
always added from the same thread.
Yea, that part of the design is deliberately conservative - get it
working, then get it working fast :-)
- Breakpoints should be removed from a cloned task, or shouldn't they?Good question. I think, if the client wants a breakpoint on the new
cloned task then they will have a cloned observer that adds breakpoints
to each cloned task.
Or should that be a property per observer?
- Is this setup powerful enough to add higher level language breakpointsYep.
on top of it?
In the end a breakpoint is reduced to an address, this code only needs
to handle those addresses. Higher level problems such as module loading
and unloading, and projecting a user level breakpoint onto one or more
of these code observers are just that, higher level problems. The high
level code calls on this and other primitives to implement those