This is the mail archive of the mailing list for the frysk project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Adding breakpoints

Mark Wielaard wrote:

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.
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.

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?
Or should that be a property per observer?
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.
- Is this setup powerful enough to add higher level language breakpoints
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 abstractions.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]