This is the mail archive of the frysk@sources.redhat.com 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: First try of breakpoint support


Hi Mark,

By using cvs source of 07-19, and applying three patches you mentioned, I had a try with the breakpoint. It seems there are some intermittent errors. The first time I run the testcase, it reported NPE on testInsertRemove, but it succeeded in the later tries. Please see the following sessions:

[woodzltc@localhost frysk-core]$ ./TestRunner -l FINEST frysk.proc.TestBreakpoints
Running testHitAndRun(frysk.proc.TestBreakpoints) ...PASS
Running testInsertRemove(frysk.proc.TestBreakpoints) ...ERROR
java.lang.NullPointerException
Running testAddLots(frysk.proc.TestBreakpoints) ...PASS


Time: 5.129
There was 1 error:
1) testInsertRemove(frysk.proc.TestBreakpoints)java.lang.NullPointerException
   at frysk.proc.TestBreakpoints.testInsertRemove(TestRunner)
   at frysk.junit.Runner.<init>(TestRunner)
   at TestRunner.main(TestRunner)

FAILURES!!!
Tests run: 3,  Failures: 0,  Errors: 1

[woodzltc@localhost frysk-core]$ ./TestRunner -l FINEST frysk.proc.TestBreakpoints
Running testHitAndRun(frysk.proc.TestBreakpoints) ...PASS
Running testInsertRemove(frysk.proc.TestBreakpoints) ...PASS
Running testAddLots(frysk.proc.TestBreakpoints) ...PASS


Time: 4.84

OK (3 tests)

[woodzltc@localhost frysk-core]$ ./TestRunner -l FINEST frysk.proc.TestBreakpoints
Running testHitAndRun(frysk.proc.TestBreakpoints) ...PASS
Running testInsertRemove(frysk.proc.TestBreakpoints) ...PASS
Running testAddLots(frysk.proc.TestBreakpoints) ...PASS


Time: 3.282

OK (3 tests)

[woodzltc@localhost frysk-core]$


Lookint through your words, I see that you also mentioned similar problems. So how are you going on with this kind of problem?


I also have some thought about general breakpoint support.

- the kprobe like mechanism to support multi-thread breakpoint seems to me a very good idea. Some candidate for holding the original instruction I can thought of are: .init section (they are not needed after the program starts up), ELF header or P-headers (storing these information somewhere else, so no need to look into them again), or an extra dynamically loaded library (through some kinds of dynamic code patching technique)

- this kind of dynamic code patching technique might also be used for fast conditional breakpoint. To say this, I means something like Dyninst (http://www.cs.umd.edu/projects/dyninstAPI/). I know it is mainly used in non-interactive dynamic instrumentation. But I am not sure if it is proper to use it in interavtive debugging. Maybe there are some other technique feasible to do similar thing in interactive debugging. Any idea on how to implement fast conditional breakpoints in Frysk?

- I see that you create a new breakpoint by hardwiring to LinuxIa32Breakpoint. We are thinking that breakpoint for LinuxPPC64 will be very similar except that we will use an illegal instruction opcode, which will trigger a SIGTRAP as well. The later work flow is the same, frysk.sys.Wait will detect this when inspecting the wait status, and handleTrappedEvent will be called. Is our understanding correct? Any thing we need to keep in mind when adding LinuxPPC64 support for this? And we will appreciate it very much if you can share your latest workable code with us.

- Hardware watchpoint hit will also delieve SIGTRAP, then watchpoint might also share some work flow with breakpoint. Do you have some consideration in this aspect?

- I remember you (or some one else) mentioned that system call tracing can't co-exist with single step. I don't have any knowledge about this before. Any reason for this? Is there any testcase to confirm this? What about inserting a breakpoint in the next instruction following system call to simulate stepping over system call?


Hi,

Here is a first try of adding breakpointing support. It works for the
attached 3 testcases which simply test that a process can be stopped,
Code observers can be added (and removed) and the updateHit() method is
called whenever the process hits the breakpoint address the Code
Observer is interested in.

It isn't integrated with the state machine yet. Which means it contains
some small hacks to force the Task into the right State at times. Adding
Code Observers is currently only supported in a Blocked state and
removing them only in the Running state. See the various XXX comments in
the patch. This also means there is no support yet for returning BLOCK
from Code.updateHit(). Even though it is clearly not finished I wanted
to post what I have to get some feedback.

The idea is as follows:
- A Proc will have a new field that holds the BreakpointAddresses.
  (breakpoints are shared between all Tasks of a Proc)
- BreakpointAddresses keep track of the actual Code Observers interested
  in an breakpoint address and request to Proc to add or remove them
  when necessary.
- A Breakpoint holds some state necessary for resetting, stepping and
  continuing. When you create a Breakpoint for a task on an address that
  is already installed you will get that instance back so it is easy to
  reset, step or continue it. Currently interaction between the
  Task/Proc is not based on the TaskState, but it obviously should. For
  now the process is forced to stop when necessary. This should be
  handled by the state machine.
- There is only support for LinuxIa32 simple INT3 breakpoints for now.
  But it should be easy to create subclasses for other architectures.
  (With a little luck I will get my hands on a x86-64/em64t style
   machine this week and will try adding support for that then.)
  Currently the stepping/continuing isn't thread/Task-safe. If there
  is another Task running while resetting the LinuxIa32Breakpoint it
  might miss hitting it temporarily.

Here are the ChangeLog entries:

2006-07-19 Mark Wielaard <mark@klomp.org>

       * frysk/proc/Breakpoint.java: New file.
       * frysk/proc/BreakpointAddresses.java: New file.
       * frysk/proc/DummyProc.java (removeBreakpoint): Dummy
       implementation.
       (addBreakpoint): Likewise.
       * frysk/proc/LinuxIa32Breakpoint.java: New file.
       * frysk/proc/LinuxProc.java (removeBreakpoint): New method.
       (addBreakpoint): New method.
       * frysk/proc/Proc.java (breakpoints): New field.
       (Proc(ProcId,Proc,Host,Task): Initialize breakpoints.
       (requestUpdateBreakpoints): New method.
       (addBreakpoint): New method.
       (removeBreakpoint): New method.
       * frysk/proc/Task.java (codeObservers): New field.
       (requestAddCodeObserver): New method.
       (requestDeleteCodeObserver): New method.
       (notifyCodeBreakpoint): New method.
       * frysk/proc/TaskObserver.java (updateHit): Update description.
       * frysk/proc/TaskState.java (running.handleTrappedEvent): New
       Method.

* frysk/proc/TestBreakpoints.java: New test.

2006-07-19 Mark Wielaard <mark@klomp.org>

* funit-breakpoints.c: New file.

The testcase depends on the the ForkedProcess support I suggested:
http://sourceware.org/ml/frysk/2006-q3/msg00065.html
Let me know if that is a good idea to add. Otherwise I can rewrite my
testcases of course. But I rather don't :)

When running by hand they always PASS:
$ ./TestRunner frysk.proc.TestBreakpoints
Running testHitAndRun(frysk.proc.TestBreakpoints) ...PASS
Running testInsertRemove(frysk.proc.TestBreakpoints) ...PASS
Running testAddLots(frysk.proc.TestBreakpoints) ...PASS

Time: 1.057

OK (3 tests)

But that depends on the PtraceByteBuffer vs errno patch that I
suggested: http://sourceware.org/ml/frysk/2006-q3/msg00077.html
Otherwise you will get some spurious interrupted system call
RuntimeExceptions.

When run with 'make check' they intermittently fail. I haven't tracked
this down yet. But it might very well be because of timing and my
failure to properly integrate this yet with the rest of the state
machine. This is my next task.

Comments and suggestions welcome.

Cheers,

Mark


Regards - Wu Zhou


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