path: root/community/gsoc/2013/hacklu.mdwn

[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[!toc]]


# IRC, freenode, #hurd, 2013-06-23

    <hacklu> braunr: sorry for the late reply. Honestly to say, the school
      works had taken most of my time these days. I haven't got any
      siginificant progress now. I am trying to write a little debugger demo on
      Hurd.
    <hacklu> braunr: things goes more hard than I think, these are some
      differences between ptrace() on Hurd and Linux. I am trying to  solve
      this.


# IRC, freenode, #hurd, 2013-06-24

    <hacklu> this is my weekly report
      http://hacklu.com/blog/gsoc-weekly-report1-117/. 
    <hacklu> and I have two main questions when I read the gdb source code. 
    <hacklu> 1/What is the S_exception_raise_request()? 2/what is the role of
      ptrace in gdb port on Hurd?
    <youpi> hacklu: where did you see S_exception_raise_request?
    <hacklu> in gdb/gnu-nat.c
    <youpi> ah, in gdb
    <hacklu> yeah. and I have read the <The hurd hacking guide>. is says the S_
      start means server stub. 
    <youpi> yes
    <youpi> what happens is that gnu_wait keeps calling mach_msg
    <youpi> to get a message
    <youpi> then it passes that message to the various stubs servers
    <youpi> see just below, it calls exc_server, among others
    <youpi> and that's exc_server which ends up calling
      S_exception_raise_request, if the message is an exception_raise request
    <youpi> exc_server is a mere multiplexer, actually
    <tschwinge> S_exception_raise_request is the implementation of the request
      part (so one half of a typical RPC) of the Mach exception interface.
    <tschwinge> See gdb/exc_request.defs in GDB and include/mach/exc.defs in
      Mach.
    <hacklu> youpi: how gnu_wait pass one message to exc_server?  in which
      function?
    <youpi> in gnu_wait()
    <youpi> && !exc_server (&msg.hdr, &reply.hdr)
    <hacklu> oh, I see this. 
    <hacklu> firstly I think it is a type check simply.
    <youpi> see the comment: "handle what we got"
    <tschwinge> The Hurd's proc server also is involved in the exception
      passing protocol (see its source code).
    <hacklu> tschwinge: I will check the source code later. is the exception
      take place in this way: 1. the inferior call ptrace(TRACE_ME). 2.the gdb
      call task_set_exception_port. 3. mach send a notification to the
      exception port set before. 4. gdb take some action.
    <tschwinge> hacklu: Yes, that's it, roughly.  The idea is that GDB replaces
      a process' standard exception port, and replaces it "with itself", so
      that when the process that is debugged receives and exception (by Mach
      sending a exception_raise RPC), GDB can then catch that and act
      accordingly.
    <tschwinge> hacklu: As for your other questions, about ptrace: As you can
      see in [glibc]/sysdeps/mach/hurd/ptrace.c, ptrace on Hurd is simply a
      wrapper around vm_read/write and more interfaces.
    <tschwinge> hacklu: As the GDB port for Hurd is specific to Hurd by
      definition, you can also directly use these calls in GDB for Hurd.
    <tschwinge> ..., as it is currently done.
    <hacklu> and in detail, the part 3 mach send a notification to the
      excetption port is like this: gnu_wait get the message in mach_msg, and
      then pass it to exc_serer by exc_server(),then exc_server call
      S_exception_raise_request()? ?
    <hacklu> tschwinge: yeah, I have see the ptrace.c. I was wonder about
      nobody use ptrace in Hurd except TRACEME...
    <tschwinge> hacklu: Right about »and in detail, [...]«.
    <tschwinge> hacklu: It would be very good (and required for your
      understanding anyway), if you could write up a list of things that
      happens when a process (both under the control of GDB as well as without
      GDB) is sent an exception (due to a breakpoint instruction, for example).
    <tschwinge> Let me look something up.
    <hacklu> tschwinge: what's the function of exc_server? if I can get the
      notification in mach_msg().
    <youpi> to multiplex the message
    <youpi> i.e. decoding it, etc. up to calling the S_ function with the
      proper parameters
    <youpi> exc_server being automatically generated, that saves a lot of code
    <tschwinge> That is generated by MIG from the gdb/exc_request.defs file.
    <tschwinge> You'll find the generated file in the GDB build directory.
    <hacklu> I have wrote down the filenames. after this I will check that.
    <tschwinge> hacklu: I suggest you also have a look at the Mach 3 Kernel
      Principles book,
      <http://www.gnu.org/software/hurd/microkernel/mach/documentation.html>.
    <tschwinge> This also has some explanation of the thread/task's exception
      mechanism.
    <tschwinge> And of course, explains the RPC mechanism, which the exception
      mechanism is built upon.
    <tschwinge> And then, really make a step-by-step list of what happens; this
      should help to better visualize what's going on.
    <hacklu> ok. later I will update this list on my blog.
    <tschwinge> hacklu: I cannot tell off-hand why GDB on Hurd is using
      ptrace(PTRACE_TRACEME) instead of doing these calls manually.  I will
      have to look that up, too.
    <hacklu> tschwinge: thanks. 
    <tschwinge> hacklu: Anyway -- you're asking sensible questions, so it seems
      you're making progress/are on track.  :-)
    <hacklu> tschwinge: there is something harder than I had thought, I haven't
      got any meaningful progress. sorry for this.
    <tschwinge> hacklu: That is fine, and was expected.  :-)  (Also, you're
      still busy with university.)
    <hacklu> I will show more time and enthusiasm on this.
    <tschwinge> hacklu: Oh, and one thing that may be confusing: as you may
      have noticed, the names of the same RPC functions are sometimes slightly
      different if different *.defs files.  What is important is the subsystem
      number, such as 2400 in [GDB]/gdb/exc_request.defs (and then incremented
      per each routine/simpleroutine/skip directive).
    <tschwinge> hacklu: Just for completeness, [hurd]/hurd/subsystems has a
      list of RPC subsystems we're using.
    <tschwinge> And the name given to routine 2400, for example, is just a
      "friendly name" that is then used locally in the code where the *.defs
      file has been processed by MIG.
    <tschwinge> What a clumsy explanation of mine.  But you'll get the idea, I
      think.  ;-)
    <tschwinge> hacklu: And don't worry about your progress -- you're making a
      lot of progress already (even if it doesn't look like it, because you're
      not writing code), but the time spent on understanding these complex
      issues (such as the RPC mechanism) definitely counts as progress, too.
    <hacklu> tschwinge: not clearly to got it as I am not sensitive with the
      MIG's grammer. But I know, the exc is the routine 2400's alias name?
    <tschwinge> hacklu: I'd like to have you spend enough time to understand
      these fundamental concepts now, and then switch to "hacking mode" (write
      code) later, instead of now writing code but not understanding the
      concepts behind it.
    <hacklu> I have wrote a bit code to validate my understanding when I read
      the soruce code. But the code not run.  http://pastebin.com/r3wC5hUp
    <tschwinge> The subsystem directive [...].  As well, let me just point you
      to the documentation:
      <http://www.gnu.org/software/hurd/microkernel/mach/mig/documentation.html>,
      MIG - THE MACH INTERFACE GENERATOR, chapter 2.1 Subsystem identification.
    <tschwinge> hacklu: Yes, writing such code for testing also is a good
      approach.  I will have to look at that in more detail, too.
    * tschwinge guesses hacklu is probably laughing when seeing the years these
        documents were written in (1989, etc.).  ;-)
    <hacklu> mach_msg make no sense in my code, and the process just hang. kill
      -9 can't stop is either.
    <braunr> hacklu: do you understand why kill -KILL might not work now ?
    <hacklu> braunr: no, but I found I can use gdb to attach to that process,
      then quit in gdb, the process quit too.
    <hacklu> maybe that process was waiting a resume.
    <braunr> something like that yes
    <braunr> iirc it's related to a small design choice in the proc server
    <braunr> something that put processes in an uninterruptible state when
      being debugged
    <hacklu> iirc ? 
    <braunr> if i recall cl=orrectly
    <braunr> correctly*
    <hacklu> like D status in linux? 
    <braunr> or T
    <braunr> there has been a lot of improvements regarding signal handling in
      linux over time so it's not really comparable now
    <braunr> but that's the idea
    <hacklu> in ps, i see the process STAT is THumx
    <braunr> did you see that every process on the hurd has at least two
      threads ?
    <hacklu> no, but I have see that in hurd, the exception handler can't live
      in the same context with the victim. so there must be at least two
      threads. I think
    <braunr> hacklu: yes
    <braunr> that thread also handles regular signals
    <braunr> in addition to mach exceptions
    <braunr> (there are two levels of multiplexing in servers, first locating
      the subsystem, then the server function)
    <braunr> hacklu: if what i wrote is confusing, don't hesitate to ask for
      clarifications (i really don't intend to make things confusing)
    <hacklu> braunr: I don't know what you say about the "multiplexing in
      servers". For instance, is it means how to pass message from  mach_msg to
      exc_server in gnu_wait()?
    <braunr> hacklu: i said that the "message thread" handles both mach
      exceptions and unix signals
    <braunr> hacklu: these are two different interfaces (and in mach terms,
      subsystems)
    <braunr> hacklu: see hurd/msg.defs for the msg interface (which handles
      unix signals)
    <braunr> hacklu: to handle multiple interfaces in the same thread, servers
      need to first find the right subsystem
    <braunr> this is done by subsequently calling all demux functions until one
      returns true
    <braunr> (finding the right server function is done by these demux
      functions)
    <braunr> hacklu: see hurd/msgportdemux.c in glibc to see how it's done
      there
    <braunr> it's short actually, i'll past it here :
    <braunr>   return (_S_exc_server (inp, outp) ||
    <braunr>           _S_msg_server (inp, outp));
    <braunr> hacklu: did that help ?
    <hacklu> braunr: a bit more confusing. one "message thread" handles
      exceptions and signals, means the message thread need to recive message
      from two port. then pass the message to the right server which handle the
      message. the server also should pick the right subsystem from a lot of
      subsystems to handle the msg. is this ? 
    <braunr> the message thread is a server thread
    <braunr> (which means every normal process is actually also a server,
      receiving exceptions and signals)
    <braunr> there may be only two ports, or more, it doesn't matter much, the
      port set abstraction takes care of that
    <hacklu> so the message thread directly pass the msg to the right
      subsystem?
    <braunr> not directly as you can see
    <braunr> it tries them all until one is able to handle the incoming message
    <braunr> i'm not sure it will help you with gdb, but it's important to
      understand for a better general understanding of the system
    <braunr> ugly sentence
    <hacklu> ah, I see. like this in gnu-nat.c  if(!notify_server(&msg.hdr,
      &reply.hdr) && !exc_server(&msg.hdr...) 
    <braunr> yes
    <hacklu> the thread just ask one by one.
    <braunr> be careful about the wording
    <braunr> the thread doesn't "send requests"
    <braunr> it runs functions
    <braunr> (one might be tempted to think there are other worker threads
      waiting for a "main thread" to handle demultiplexing messages)
    <hacklu> I got it.
    <hacklu> the notify_server function is just run in the same context in
      "message thread",and there is no RPC here. 
    <braunr> yes
    <hacklu> and the notify_server code is generater by mig automatically.
    <braunr> yes


# IRC, freenode, #hurd, 2013-06-29

[[!tag open_issue_documentation]]

    <hacklu> I just failed to build the demo on
      this. http://walfield.org/pub/people/neal/papers/hurd-misc/ipc-hello.c
    <hacklu> or, example in machsys.doc called simp_ipc.c
    <pinotree> we don't use cthreads anymore, but pthreads
    <hacklu> pinotree: em.. and I also failed to find the <servers/env_mgr.h>
      in example of <A programmer's guide to MACH system call>
    <pinotree> that i don't know
    <hacklu> maybe the code in that book out-of-date
    <teythoon> hacklu: mig and mach ipc documentation is quite dated
      unfortunately, and so are many examples floating around the net

    <hacklu> btw, I have one more question. when I read <Mach 3 kernel
      interface>. I find this state: When an exception occurs in a thread, the
      thread sends an exception message to
    <hacklu> its exception port, blocking in the kernel waiting for the receipt
      of a reply. It is
    <hacklu> assumed that some task is listening to this
    <hacklu> port, using the  exc_serverfunction to decode the messages and
      then call the
    <hacklu> linked in  catch_exception_raise. It is the job of
      catch_exception_raiseto handle the exception and decide the course of
      action for thread.
    <hacklu> that says, it assumed another task to recieve the msg send to one
      thread's exception port. why another task? 
    <hacklu> I remmebered, there are at least two threads in one task, one is
      handle the exception stuffs.
    <braunr> there are various reasons
    <braunr> first is, the thread causing the exception is usually not waiting
      for a message
    <braunr> next, it probably doesn't have all the info needed to resolve the
      exception
    <braunr> (depending on the system design)
    <braunr> and yes, the second thread in every hurd process is the msg
      thread, handling both mach exceptions and hurd signals
    <hacklu> but in this state, I can't find any thing with the so called msg
      thread
    <braunr> ?
    <hacklu> if exist a task to do the work, why we need this thread?
    <braunr> this thread is the "task"
    <hacklu> ?
    <braunr> the msg thread is the thread handling exceptions for the other
      threads in one task
    <braunr> wording is important here
    <braunr> a task is a collection of resources
    <braunr> so i'm only talking about threads really
    <braunr> 14:11 < hacklu> assumed that some task is listening to this
    <braunr> this is wrong
    <braunr> a task can't listen
    <braunr> only a thread can
    <hacklu> in you words, the two thread is in the same task?
    <braunr> yes
    <braunr> 14:32 < braunr> and yes, the second thread in every hurd process
      is the msg thread, handling both mach exceptions and hurd signals
    <braunr> process == task here
    <hacklu> yeah, I always think the two thread stay in one task. but I found
      that state in <mach 3 kernel interface>. so I confuzed
    <hacklu> s/confuzed/confused
    <braunr> statement you mean
    <hacklu> if two thread stay in the same task. and the main thread throw a
      exception, the other thread to handle it?
    <braunr> depends on how it's configured
    <braunr> the thread receiving the exceptions might not be in the same task
      at all
    <braunr> on the hurd, only the second thread of a task receives exception
    <braunr> s
    <hacklu> I just wonder how can the second thread catch the exception from
      its containning task
    <braunr> forget about tasks
    <braunr> tasks are resource containers
    <braunr> they don't generate or catch exceptions
    <braunr> only threads do
    <braunr> for each thread, there is an exception port
    <braunr> that is, one receive right, and potentially many send rights
    <braunr> the kernel uses a send right to send exceptions
    <braunr> the msg thread waits for messages on the receive right
    <braunr> that's all
    <hacklu> ok. if I divide zero in main thread, the kernel will send a msg to
      the main thread's exception port. and then, the second thread(in the same
      task) is waiting on that port. so he get the msg. is it right?
    <braunr> don't focus on main versus msg thread
    <braunr> it applies to all other threads
    <braunr> as well
    <braunr> otherwise, you're right
    <hacklu> ok, just s/main/first
    <braunr> no
    <braunr> main *and* all others except msg
    <hacklu> main *and* all others except msg ?
    <braunr> the msg thread gets exception messages for all other threads in
      its task
    <braunr> (at least, that's how the hurd configures things)
    <hacklu> got it.
    <hacklu> if the msg thread throw exception either, who server for himself?
    <braunr> i'm not sure but i guess it's simply forbidden
    <hacklu> i used gdb to attach a little progrom which just contains a divide
      zero. and I only found the msg thread is in the glibc.  
    <braunr> yes
    <hacklu> where is the msg thread located in. 
    <braunr> it's created by glibc
    <hacklu> is it glibc/hurd/catch-exc.c?
    <braunr> that's the exception handling code, yes
    <hacklu> there are some differences between the code and the state in <mach
      3 system interface>.
    <braunr> state or statement ?
    <hacklu> staement
    <braunr> which one ?
    <hacklu> http://pastebin.com/ZTBrUAsV
        When an exception occurs in a thread, the thread sends an exception
          message to
        its exception port, blocking in the kernel waiting for the receipt of a
          reply. It is
        assumed that some task is listening (most likely with mach_msg_server)
          to this
        port, using the  exc_serverfunction to decode the messages and then
          call the
        linked in  catch_exception_raise. It is the job of
          catch_exception_raiseto handle the exception and decide the course of
          action for  thread. The state of the
        blocked thread can be examined with thread_get_state.
    <braunr> what difference ?
    <hacklu> in the code, I can't find things like exc_server,mach_msg_server
    <braunr> uh
    <braunr> ok it's a little tangled
    <braunr> but not that much
    <braunr> you found the exception handling code, and now you're looking for
      what calls it
    <braunr> simple
    <braunr> see _hurdsig_fault_init
    <hacklu> from that statemnet I thought there are another _task_ do the
      exception things for all of the systems thread before you have told me
      the task means the msg thread.
    <braunr> again
    <braunr> 14:47 < braunr> forget about tasks
    <braunr> 14:47 < braunr> tasks are resource containers
    <braunr> 14:47 < braunr> they don't generate or catch exceptions
    <braunr> 14:47 < braunr> only threads do
    <hacklu> yeah, I think that document need update.
    <braunr> no
    <braunr> it's a common misnomer
    <braunr> once you're used to mach concepts, the statement is obvious
    <hacklu> braunr: so I need read more :)
    <hacklu> _hurdsig_fault_init send exceptions for the signal thread to the
      proc server?
    <hacklu> why come about _proc_ server?
    <braunr> no it gives the proc server a send right for signals
    <braunr> exceptions are a mach thing, signals are a hurd thing
    <braunr> the important part is
    <braunr>   err = __thread_set_special_port (_hurd_msgport_thread,
    <braunr>                                    THREAD_EXCEPTION_PORT, sigexc);
    <hacklu> this one set the exception port?
    <braunr> yes
    <braunr> hm wait
    <braunr> actually no, wrong part :)
    <braunr> this sets the excpetion port for the msg thread (which i will call
      the signal thread as mentioned in glibc)
    <hacklu> but the comment above this line, Direct signal thread exceptions
      to the proc server  means what?
    <braunr> that the proc server handles exceptions on the signal thread
    <hacklu> the term signal thread equals the term msg thread?
    <braunr> yes
    <hacklu> so, the proc server handles the exceptions throwed by the msg
      thread?
    <braunr> looks that way
    <hacklu> feels a little strange.
    <braunr> why ?
    <braunr> this thread isn't supposed to cause exceptions
    <braunr> if it does, something is deeply wrong, and something must clean
      that task up
    <braunr> and the proc server seems to be the most appropriate place from
      where to do it
    <hacklu> why need a special server to just work the msg thread? I don't
      think that thread will throw exception frequentlly
    <braunr> what does frequency have to do with anything here ?
    <braunr> ok the appropriate code is _hurdsig_init
    <braunr> the port for receiving exceptions is _hurd_msgport
    <braunr> the body of the signal thread is _hurd_msgport_receive
    <hacklu> aha, in the _hurd_msgport_receive I have finally found the
      while(1) loop mach_msg_server().
    <hacklu> so the code is conform with the documents. 
    <hacklu> braunr: [21:18] <braunr> what does frequency have to do with
      anything here ? yes, I have totally understood your words now. thank you
      very much.
    <braunr> :)


# IRC, freenode, #hurd, 2013-07-01

    <hacklu> hi. this is my weekly
      report. http://hacklu.com/blog/gsoc-weekly-report2-124/ welcome to any
      comment
    <hacklu> teythoon: I only get clear about the rpc stuff. seems a lot behind
      my plan 
    <youpi> good progress :)
    <hacklu> I have wrote the details of the exception handle which was asked
      by tschwing_ last week. Am I all right in my post?
    <youpi> hacklu: as far as I understand signals, yes :)
    <hacklu> youpi: thanks for god, I am on the right way finally... :)
    <hacklu> the mig book says simpleroutine is the one use to implement asyn
      RPCs which doesn't expect an reply. But I have found a place to pass an
      reply port to the RPC interface which has been declared as simpleroutine
    <youpi> hacklu: probably the simpleroutine hardcodes a reply port?

    <youpi> hacklu: about _hurd_internal_post_signal, this is the hairiest part
      of GNU/Hurd, signal handling
    <youpi> simply because it's the hairiest part of POSIX :)
    <youpi> you probably want to just understand that it implements the
      POSIXity of signal delivering
    <youpi> i.e. deliver/kill/suspend the process as appropriate
    <youpi> I don't think you'll need to dive more
    <hacklu> aha. 
    <hacklu> it will save a lot of time.
    <hacklu> it seems like the wait_for_inferior() in gdb. which also has too
      many lines and too many goto
    <youpi> hacklu: btw, which simpleroutine were you talking  about ?
    <hacklu> I forget where it is, I am finding it now.
    <youpi> which version of gdb are you looking the source of?
    <youpi> (in mine, wait_for_inferior is only 45 lines long)
    <hacklu> I dont know how to pick the verison, I just use the git
      version. maybe I give a wrong name.
    <youpi> ok
    <hacklu> youpi:I remembered, my experience comes from here
      http://www.aosabook.org/en/gdb.html. (All of this activity is managed by
      wait_for_inferior. Originally this was a simple loop, waiting for the
      target to stop and then deciding what to do about it, but as ports to
      various systems needed special handling, it grew to a thousand lines,
      with goto statements criss-crossing it for poorly understood 
    <hacklu> reasons.)
    <hacklu> youpi: the simpleroutine is gdb/gdb/exc_request.defs
    <youpi> so there is indeed an explicit reply port
    <hacklu> but simpleroutine is for no-reply use. why use reply port here?
    <youpi> AIUI, it's simply a way to make the request asynchronous, but still
      permit an answer
    <hacklu> ok, I will read the mig book carefully.
    <braunr> hacklu: as youpi says
    <braunr> a routine can be broken into two simpleroutines
    <braunr> that's why some interfaces have interface.defs,
      interface_request.defs and interface_reply.defs files
    <braunr> nlightnfotis: in mach terminology, a right *is* a capability
    <braunr> the only thing mach doesn't easily provide is a way to revoke them
      individually
    <nlightnfotis> braunr: Right. And ports are associated with the process
      server and the kernel right? I mean, from what I have understood, if a
      process wants to send a signal to another one, it has to do so via the
      ports to that process held by the process server
    <nlightnfotis> and it has to establish its identity before doing so, so
      that it can be checked if it has the right to send to that port.
    <braunr> yes
    <nlightnfotis> do process own any ports? or are all their ports associated
      with the process server?
    <nlightnfotis> *processes
    <braunr> mach ports were intended for a lot of different uses
    <braunr> but in the hurd, they mostly act as object references
    <braunr> the process owning the receive right (one at most per port)
      implements the object
    <braunr> processes owning send rights invoke methods on the object
    <braunr> use portinfo to find out about the rights in a task
    <braunr> (process is the unix terminology, task is the mach terminologyà
    <braunr> )
    <braunr> i use them almost interchangeably
    <nlightnfotis> ahh yes, I remember about the last bit. And mach tasks have
      a 1 to 1 association with user level processes (the ones associated with
      the process server)
    <braunr> the proc server is a bit special because it has to know about all
      processes
    <braunr> yes

In context of [[open_issues/libpthread/t/fix_have_kernel_resources]]:

    <braunr> hacklu: if you ever find out about either glibc or the proc server
      creating one receive right for each thread, please let me know


# IRC, freenode, #hurd, 2013-07-07

    <hacklu> how fork() goes? 
    <pinotree> see sysdeps/mach/hurd/fork.c in glibc' sources
    <hacklu> when the father has two thread( main thread and the signal thead),
      if the father call fork, then the child inmediatelly call exev() to
      change the excute file. how many thread in the children?
    <hacklu> For instance, the new execute file also have two thread. 
    <hacklu> will the exev() destroyed two threads and then create two new?
    <hacklu> s/exev()/excv()
    <hacklu> s/exev()/exec() :)

    <hacklu> what libhurduser-2.13.so does?
    <hacklu> where can I find this source?
    <pinotree> contains all the client stubs for hurd-specific RPCs
    <pinotree> it is generated and built automatically within the glibc build
      process

    <hacklu> and what is the "proc" server?
    <pinotree> what handles in user spaces the processes
    <hacklu> so if  I call proc_wait_request(),  I will go into the
      S_proc_wait_reply?
    <hacklu> thanks, I have found that. 


# IRC, freenode, #hurd, 2013-07-08

    <hacklu> hi, this is my weekly
      report. http://hacklu.com/blog/gsoc-weekly-report3-137/
    <hacklu> this week I have met a lot of obstacles. And I am quite desired to
      participate in this meeting.
    <tschwinge> hacklu: So from your report, the short version is: you've been
      able to figure out how the things work that you were looking at (good!),
      and now there are some new open questions that you're working on now.
    <tschwinge> hacklu: That sounds good.  We can of course try to help with
      your open questions, if you're stuck figuring them out on your own.
    <hacklu> tschwinge: the most question is: what is the proc server? why need
      to call proc_get_reqeust() before the mach_msg()?
    <hacklu> and 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). which I have post in my report. 
    <tschwinge> hacklu: The fork man-page can provide a high-level answer to
      your Q3: »The child process is created with a single thread—the one that
      called fork().  The entire virtual address space of the parent is
      replicated in the child, including the states of mutexes, condition
      variables, and other pthreads objects [...]«
    <tschwinge> hacklu: What happens in GNU Hurd is that the signal thread is
      also "cloned" (additionally to the thread which called fork), but then it
      (the signal thread) is re-started from the beginning.  (So this is very
      much equivalent to creating a new signal thread.)
    <tschwinge> hacklu: Then, upon exec, a new memory image is created/loaded,
      replacing the previous one.  [glibc]/sysdeps/mach/hurd/execve.c.  What
      actually happens with the existing thread (in particular, the signal
      thread) I don't know off-hand.  Then answer is probably found in
      [glibc]/hurd/hurdexec.c -- and perhaps some code of the exec server
      ([hurd]/exec/).
    <hacklu> I have checked the status of my regiter mail to FSF. it says it
      had arrived in USA. 
    <tschwinge> hacklu: OK, good.
    <tschwinge> hacklu: This is some basic information about the observer_*
      functions is GDB:
      http://sourceware.org/gdb/current/onlinedocs/gdbint/Algorithms.html#index-notifications-about-changes-in-internals-57
      »3.10 Observing changes in gdb internals«.
    <hacklu> tschwinge: not too clear. I will think this latter. and what is
      the proc server?
    <teythoon> hacklu: /hurd/proc, maps unix processes to mach threads afaiui
    <hacklu> teythoon: question is, the mach_msg() will never return unless I
      called proc_wait_request() first.
    <teythoon> hacklu: sorry, I've no idea ;)
    <hacklu> teythoon: :)
    <tschwinge> hacklu: I will have to look into that myself, too; don't know
      the answer off-hand.
    <tschwinge> hacklu: In your blog you write proc_get_request -- but such a
      functions doesn't seems to exist?
    <hacklu> tschwinge: s/proc_get_request/proc_wait_request  called in
      gun_wait() [gnu-nat.c]
    <tschwinge> hacklu: Perhaps the wait man-page's description of WUNTRACED
      gives a clue: »also return if a child has stopped [...]«.  But it also to
      me is not yet clear, how this relates to the mach_mag call, and how the
      proc server exactly is involved in it.
    <tschwinge> I'm reading various source code files.
    <tschwinge> At least, I don't undestand why it is required for an exception
      to be forwarded.
    <hacklu> if I need to read the proc server source code?
    <tschwinge> I can see how it to become relevant for the case that GDB has
      to be informed that the debugee has exited normally.
    <tschwinge> hacklu: Yeah, probably you should spend some time with that, as
      it will likely help to get a clearer picture of the situation, and is
      relevant for other interactions in GDB, too.
    <tschwinge> hacklu: By the way, if you find that pieces of the GDB source
      code (especially the Hurd files of it) are insufficiently documented,
      it's a very good idea, once you have figured out something, to add more
      source code comments to the existing code.  Or writed these down
      separately, if that is easier.
    <hacklu> which is the proc server? hurd/exec ?
    <hacklu> that ok, I already comment things on my notes. 
    <tschwinge> hacklu: [Hurd]/proc/
    <tschwinge> hacklu: And [Hurd]/hurd/process*.defs
    <hacklu> got it
    <tschwinge> hacklu: I'll have to experiment a bit with your HDebugger
      example, but I'm out of time right now, sorry.  Will continue later.
    <hacklu> tschwinge: yep, the HDebugger has a problem, if you put the
      sleep() after the printf in the just_print(), thing will hang. 
    <hacklu> tschwinge: and I am a little curious about how do you find my
      code? I dont't remember I have mentioned that :)
    <hacklu> tschwinge: I have post my gihub link in the last week report, I
      found that.
    <tschwinge> hacklu: That's how I found it, yes.
    <hacklu> tschwinge: :)