[GSoC weekly report#4]can't resume from a breakpoint

This is my code of HDebugger under GNU/Hurd.  The mainly problem is that it can set a breakpoint but can't resume from it.

The inferior program is just like a hello_world but contains two printf() call. Firstly, I set a breakpoint at the second printf() call, the address if find in the output by objdump -d.

Now, I can get the exception message (which msg.id==2400) from the mach kernel when the inferior hit the breakpoint. When get the message, I recovery the breakpoint of the original code, and set the thread_state by minus the eip register . Then post a signal_0 to it. At last I call thread_resume() try to continue inferior. But I got nothing, the thread is just keeping hang. If I use gdb to attach the inferior when I got the exception message, I can continue the inferior by type "continue command" in gdb' shell.

Answer to  last week:

  1. If  I don’t call proc_wait_request()first in my debugger demo, the mach_msg() call  will never return. This is because the inferior is suspended after execl(), so nobody will send message to us if we don't do a request initiatively.
  2. Is  there exist any specific running sequence between father and child task after fork()? By default, after fork(), the father process run first, so we have a chance to see the execl() to destroy the old threads in child process.
  3. How execl() go? It will destroy the two old threads(main thread and signal thread) forked from the parent process.  Then create a new main thread to run the execute file in execl() parameter. The funny thing is when to create the new signal thread? Never create the signal thread unless an exception appears(NO! The signal thread is initialize early and loop listening on the msgport). This is also the answer to question 4.
Next week goal:
Finish HDebugger and begin to code the gdbserver!


Leave a Reply

Your email address will not be published.