[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!


[GSoC weekly report#3]dig into the gnu_nat.c

This week I have digged into the GDB source code. I have turn on the gnu_debug_flags in gnu_nat.c, and get about 500 lines output when debugging a hello_world program. Then I try to get clear about the detail of GNU/Hurd follow the output step by step. But I have got a lot of puzzles.

  1. What is the proc server?. And I found that If  I don’t call proc_get_reqeust() proc_wait_request()first in my debugger demo, the mach_msg() call  will never return.
  2. Is  there exist any specific running sequence between father and child task after fork()? And I found the inferior always call the trace_me() in the same time(the trace me printf always in the same line of the output log).
  3. How do the fork() and execl() go? Say there is a father task which contains two threads( one for main thread, and other is the signal thread). After the father call fork(), the child call execl() immediately, how things go? Will execl() destroy the two old threads and then create new ones?
  4. When I set a breakpoint in the hello_world program, I will get five times new thread printf and three threads died printf. If I don't set breakpoint, I only get four times, and two threads died. How to explain this?
  5. How to understand the relationship and difference between structure inf  and structure inferior? I think the inf is low-level presentation of the debugged program, and the other is a high-level presentation. Am I right?
  6. what are the observer_notify_new_thread()  and observer_notify_thread_ptid_changed() do in thread.c?
  7. What are the target_terminal_*() [fork_child.c] like target_terminal_init() and target_ternimal_inferior() do?

Next week goal: solve above questions.