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 [[service_solahart_jakarta_selatan__082122541663/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: :)


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

    <hacklu> hi. what is a process's msgport? 
    <hacklu> And where can I find the msg_sig_post_untraced_request()?
    <hacklu> (msg_sig_post* in [hurd]/hurd/msg_defs)
    <hacklu> this is my debugger demo code
      https://github.com/hacklu/HDebugger.git use make test to run the demo. I
      put a breakpoint before the second printf in hello_world(inferior
      program).  but I can't resume execution from that.
    <hacklu> could somebody give me some suggestions? thanks so much.
    <teythoon> hacklu: % make test
    <teythoon> make: *** No rule to make target `exc_request_S.c', needed by
      `all'.  Stop.
    <hacklu_> teythoon: updated, forget to git add that file .
    <teythoon> hacklu_: cool, seems to work now
    <teythoon> will look into this tomorrow :)
    <hacklu_> exit
    <hacklu_> teythoon: not work. the code can,t resume from a breakpoint 


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

    <hacklu> hi, this is my weekly
      report. http://hacklu.com/blog/gsoc-weekly-report4-148/
    <hacklu> sadly to unsolve the question of resume from breakpoint.
    <teythoon> hacklu: have you tried to figure out what gdb does to resume a
      process?
    <hacklu> teythoon: hi. em, I have tried, but haven't find the magic in gdb
      yet.
    <teythoon> have you tried rpctrace'ing gdb?
    <hacklu> no, rpctrace has too many noise. I turned on the debug in gdb.
    <hacklu> I don't want rpctrace start gdb as its child task. if it can
      attach at some point instead of at start
    <teythoon> hacklu: you don't need to use gdb interactively, you could pipe
      some commands to it
    <hacklu> teythoon: that sounds a possible way. I am try it, thank you 
    <hacklu> youpi: gdb can't work correctlly with rpctrace even in batch
      mode. 
    <hacklu> get something like this "rpctrace: get an unknown send right from
      process 2151"
    <youpi> hacklu: well, ideally, fix rpctrace );
    <youpi> ;)
    <youpi> hacklu: but you can also as on the list, perhaps somebody knows
      what you need
    <hacklu> ok.
    <hacklu> or I should debug gdb more deeply.
    <youpi> do both
    <youpi> so either of them may win first

    <hacklu> braunr: I have found that, if there is no exception appears, the
      signal thread will not be createed. Then there is only one thread in the
      task.


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

    <hacklu__> braunr: ping
    <braunr> hacklu__: yes ?
    <hacklu__> I have reply your email
    <braunr> i don't understand
    <braunr> "I used this (&_info)->suspend_count to get the sc value."
    <braunr> before the thread_info call ?
    <hacklu__> no, after the call
    <braunr> but you have a null pointer
    <braunr> the info should be returned in info, not _info
    <hacklu__> strange thing is the info is a null pointer. but _info not
    <braunr> _info isn't a pointer, that's why
    <braunr> the kernel will use it if the data fits, which is usually the case
    <hacklu__> in the begin , the info=&_info.
    <braunr> and it will dynamically allocate memory if it doesn't
    <braunr> yes
    <braunr> info should still have that value after the call
    <hacklu__> but the call had change it. this is what I can;t understand.
    <braunr> are you completely sure err is 0 on return ?
    <hacklu__> since the parameter is a pointer to pointer, the thread_info can
      change it , but I don't think it is a good ideal to set it to null
      pointer without any err .
    <hacklu__> yes. i am sure
    <braunr> info_len is wrong
    <braunr> it should be the number of integers in _info
    <braunr> i.e. sizeof(_info) / sizeof(unsigned int)
    <braunr> i don't think that's the problem though
    <braunr> yes, THREAD_BASIC_INFO_COUNT is already exactly that
    <braunr> hm not exactly
    <braunr> yes, exactly in fact
    <hacklu__> I try to set it by hand, not use the macro.
    <braunr> the macro is already defined as #define THREAD_BASIC_INFO_COUNT
      (sizeof(thread_basic_info_data_t) / sizeof(natural_t))
    <hacklu__> the info_len is 13. I checked.
    <braunr> so, i said something wrong
    <braunr> the call doesn't reallocate thread_info
    <braunr> it uses the provided storage, nothing else
    <braunr> yes, your call is wrong
    <braunr> use thread_info (thread->port, THREAD_BASIC_INFO, (int *) info,
      &info_len);
    <hacklu__> em. thread_info (thread->port, THREAD_BASIC_INFO, (int *) &info,
      &info_len);
    <braunr> &info would make the kernel erase the memory where info (the
      pointer) was stored
    <braunr> info, not &info
    <braunr> or &_info directly
    <braunr> i don't see the need for an intermediate pointer here
    <braunr> ideally, avoid the cast
    <hacklu__> but in gnu-nat.c line 3338, it use &info.
    <braunr> use a union with both thread_info_data_t and
      thread_basic_info_data_t
    <braunr> well, try it my way
    <braunr> i think they're wrong
    <hacklu__> ok, you are right, use info it is ok. the value is the same as
      &_info after the call.
    <hacklu__> but the  suspend_count is zero  again.
    <braunr> check the rest of the result to see if it's consistent
    <hacklu__> I think this line need a patch. 
    <hacklu__> what you mean the rest of the result?
    <braunr> the thread info
    <braunr> run_state, sleep_time, creation_time
    <braunr> see if they make sense
    <hacklu__> ok, I try to dump it
    <braunr> bbl
    <hacklu__> braunr: thread [118] suspend_count=0
    <hacklu__> run_state=3, flags=1, sleep_time=0,
      creation_time.second=1374079641
    <hacklu__> something like this, seems no problems.


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

    <hacklu__> how to get the thread state from TH_STATE_WAITING to
      TH_STATE_RUNNING
    <braunr> hacklu__:
      http://www.gnu.org/software/hurd/gnumach-doc/Thread-Execution.html#Thread-Execution
    <braunr> hacklu__: ah waiting
    <braunr> hacklu__: this means the thread is waiting for an event
    <braunr> so probably waiting for a message
    <braunr> or an internal kernel event
    <hacklu__> braunr: so I need to send it a message. I think I maybe forget
      to send some reply message.
    <braunr> hacklu__: i'm really not sure about those low level details
    <braunr> confirm before doing anything
    <hacklu__> the gdb has called msg_sig_post_untraced_request(), I don't get
      clear about this function, I just call it as the same, maybe I am wrong .
    <hacklu__> how will if I send a CONT to the stopped process? maybe I should
      try this.
    <hacklu__> when the inferior is in waiting
      status(TH_STATE_WAITING,suspend_count=0), I use kill to send a CONT. then
      the become(TH_STATE_STOP,suspend_count=1). when I think I am near the
      success,I call thread_resume(),inferior turn out to be (TH_STATE_WAITING,
      suspend_count=0).
    <braunr> so yes, probably waiting for a message
    <hacklu__> braunr: after send a CONT to the inferior, then send a -9 to the
      debugger, the inferior continue!!!
    <braunr> probably because it was notified there wasn't any sender any more
    <hacklu__> that's funny, I will look deep into thread_resume and kill
    <braunr> (gdb being the sender here)
    <hacklu__> in hurd, when gdb attach a inferior, send signal to the
      inferior, who will get the signal first? the gdb or the inferior?
    <hacklu__> quite differnet with linux. seems the inferior get first
    <braunr> do you mean gdb catches its own signal through ptrace on linux ?
    <hacklu__> kkk
    <braunr> ?


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

    <hacklu> braunr: yeah, on Linux the gdb catch the signal from inferior
      before the signal handler. And that day my network was broken, I can't
      say goodbye to you. sorry for that.


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

    <hacklu> hi all, this is my weekly
      report. http://hacklu.com/blog/gsoc-weekly-report5-152/
    <teythoon> good to hear that you got the resume issue figured out
    <hacklu> teythoon: thanks :)
    <teythoon> hacklu: so your next step is to port gdbserver to hurd?
    <hacklu> yep, I am already begin to.
    <hacklu> before the mid-evaluate, I must submit something. I am far behind
      my personal expections
    <tschwinge> hacklu: You've made great progress!  Sorry, for not being able
      to help you very much: currently very busy with work.  :-|
    <tschwinge> hacklu: Working on gdbserver now is fine.  I understand you
      have been working on HDebugger to get an understanding of how everyting
      works, outside of the huge GDB codebase.  It's of course fine to continue
      working on HDebugger to test things, etc., and that also counts very much
      for the mid-term evaluation, so nothing to worry about.  :-)
    <hacklu> but I have far away behind my application on GSOC. I haven't
      submit any patches. is it ok?
    <tschwinge> hacklu: Don't worry.  Before doing the actual work, things
      always look much simpler than they will be.  So I was expecting/planning
      for that.
    <tschwinge> The Hurd system is complex, with non-trivial and sometimes
      asynchronous communication between the different components, and so it
      takes some time to get an understanding of all that.
    <hacklu> yes, I haven't get all clear about the signal post. that's too
      mazy.
    <tschwinge> hacklu: It surely is, yes.
    <hacklu> tschwinge: may you help me to understand the msg_sig_post(). I
      don't want to understand all details now, but I want to get the _right_
      understanding of the gerneral.
    <hacklu> as I have mentioned on my weekly report, gdb is listening on the
      inferior's exception port, then gdb post a signal to that port. That
      says: gdb post a message to herself, and handle it. is this right?
    <hacklu> tschwinge: [gdb]/gdb/gnu-nat.c (line 1371), and
      [glibc]/hurd/hurdsig.c(line 1390)
    <tschwinge> hacklu: My current understanding is that this is a "real"
      signal that is sent to the debugged process' signal thread (msgport), and
      when that process is resumed, it will process that signal.
    <tschwinge> hacklu: This is different from the Mach kernel sending an
      exception signal to a thread's exception port, which GDB is listening to.
    <tschwinge> Or am I confused?
    <hacklu> is the msgport equal the exception port?
    <hacklu> in my experience, when the thread haven't  cause a exception, the
      signal thread will not be created. after the exception occured, the
      signal thread is come out. so somebody create it, who dose? the mach
      kernel? 
    <tschwinge> hacklu: My understanding is that the signal thread would always
      be present, because it is set up early in a process' startup.
    <hacklu> but when I call task_threads() before the exception appears, only
      on thread returned.
    <tschwinge> "Interesting" -- another thing to look into.
    <tschwinge> hacklu: Well, you must be right: GDB must also be listening to
      the debugged process' msgport, because otherwise it wouldn't be able to
      catch any signals the process receives.  Gah, this is all too complex.
    <hacklu> tschwinge: that's maybe not. gdb listening on the task's exception
      port, and the signal maybe handle by the signal thread if it could
      handle. otherwise the signal thread pass the exception to the task's
      exception port where gdb catched.
    <tschwinge> hacklu: Ah, I think I now get it.  But let me first verify...
      ;-)

    <hacklu> something strange. I have write a program to check whether create
      signal threads at begining, the all created!
    <hacklu> tschwinge: this is my test code and
      result. http://pastebin.com/xtM6DUnG  
        cat test.c
        #define _GNU_SOURCE 1
        #include <stdlib.h>
        #include <stdio.h>
        #include <errno.h>
        #include <mach.h>
        #include <mach_error.h>
        int main(int argc,char** argv)
        {
                mach_port_t task_port;
                thread_array_t threads[5];
                mach_msg_type_number_t num_threads[5];
                error_t err;
                task_port = mach_task_self();
                int i;
                int j;
                for(i=0;i<5;i++)
                        if(task_port){
                                err = task_threads(task_port,&threads[i],&num_threads[i]);
                                if(err)
                                        printf("err\n");
                        }
                for(i=0;i<5;i++){
                                printf("===============\n");
                                printf("has %d threads now\n",num_threads[i]);
                                for(j=0;j<num_threads[i];j++)
                                        printf("thread[%d]=%d\n",j,threads[i][j]);
                }
                return 0;
        }
        
        
        and the output
        ./a.out
        ===============
        has 2 threads now
        thread[0]=87
        thread[1]=97
        ===============
        has 2 threads now
        thread[0]=87
        thread[1]=97
        ===============
        has 2 threads now
        thread[0]=87
        thread[1]=97
        ===============
        has 2 threads now
        thread[0]=87
        thread[1]=97
        ===============
        has 2 threads now
        thread[0]=87
        thread[1]=97
    <hacklu> tschwinge: the result is different with HDebugger case.

    <tschwinge> hacklu: It is my understanding that the two sig_post_untraced
      RPC calls in inf_signal indeed are invoked on the real msgport (signal
      thread) if the debugged process.
    <tschwinge> That port is retrieved via the
      INF_MSGPORT_RPC/INF_RESUME_MSGPORT_RPC macro, which invoked
      proc_getmsgport on the proc server, and that will return (unless
      overridden by proc_setmsgport, but that isn't done in GDB) the msgport as
      set by [glibc]/hurd/hurdinit.c:_hurd_new_proc_init or _hurd_setproc.
    <tschwinge> inf_signal is called from gnu_resume, which is via
      [target_ops]->to_resume is called from target.c:target_resume, which is
      called several places, for example infrun.c:resume which is used to a)
      just resume the debugged process, or b) resume it and have it handle a
      Unix signal (such as SIGALRM, or so), when using the GDB command »signal
      SIGALRM«, for example.
    <tschwinge> So such a signal would then not be intercepted by GDB itself.
    <tschwinge> By the way, this is all just from reading the code -- I hope I
      got it all right.

    <tschwinge> Another thing: In Mach 3 Kernel Principles, the standard
      sequence described on pages 22, 23 is thread_suspend, thread_abort,
      thread_set_state, thread_resume, so you should probably do that in
      HDebugger too, and not call thread_set_state before.
    <tschwinge> I would hope the GDB code also follows the standard sequence?
      Can you please check that?

    <tschwinge> The one thing I'm now confused about is where/how GDB
      intercepts the standard setup (probably in glibc's signaling mess?) so
      that it receives any signals raised in the debugged process.
    <tschwinge> But I'll have to continue later.

    <hacklu___> tschwinge: thanks for your detail answers. I don't realize that
      the gnu_resume will resume for handle a signal, much thanks for point
      this:) 
    <hacklu___> tschwinge: I am not exactly comply with <Mach 3 kernel
      principles> when I call thread_set_state. but I have called a
      task_suspend before. I think it's not too bad:)
    <tschwinge> hacklu___: Yes, but be aware that gnu_resume is only relevant
      if a signal is to be forwarded to the debugged process (to be handled
      there), but not for the case where GDB intercepts the signal (such as
      SIGSEGV), and handles it itself without then forwarding it to the
      application.  See the »info signals« GDB command.
    <hacklu___> I also confused about when to start the signal thread. I will
      do more experiment.
    <hacklu___> I have found this: when the inferior is stop at a breakpoint, I
      use kill to send a CONT to it, the HDebugger will get this message who
      listening on the exception port.


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

    <hacklu_> how to understand the rpctrace output? 
    <hacklu_> like this.  142<--143(pid15921)->proc_mark_stop_request (19 0)
      125<--1
    <hacklu_> 27(pid-1)->msg_sig_post_request (20 5  task108(pid15919));
    <hacklu_> what is the (pid-1)? the kernel?
    <teythoon> 1 is /hurd/init
    <hacklu_> pid-1 not means minus 1?
    <teythoon> ah, funny, you're right... I dunno then
    <teythoon> 2 is the kernel though
    <hacklu_> the 142<--143 is port name?
    <teythoon> could very well be, but I'm not sure, sorry
    <hacklu_> the number must be the port name. 
    <teythoon> anyone knows why /hurd/init does not get dead name notifications
      for /hurd/exec like it does for any other essential server?
    <teythoon> as far as I can see it successfully asks for them
    <teythoon> about rpctrace, it poses as the kernel for its children, parses
      and relays any messages sent over the childrens message port, right?


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

    <hacklu_> hi. this is my weekly
      report. http://hacklu.com/blog/gsoc-weekly-report6-156/
    <teythoon> hacklu_: the inferior voluntarily stops itself if it gets a
      signal and notifies its tracer?
    <hacklu_> yes
    <teythoon> what if it chose not to do so? undebugable program?
    <hacklu_> debugged program will be set an flag so called
      hurdsig_traced. normal program will handle the signal by himself.
    <hacklu_> in my env, I found that when GDB attach a running program, gdb
      will not catch the signal send to the program. May help me try it?
    <teythoon> it doesn't? I'll check...
    <teythoon> hacklu_: yes, you're right
    <hacklu_> you can just gdb a loop program, and kill -CONT to it. If I do
      this I will get "Can't wait for pid 12332:NO child processes" warning.
    <teythoon> yes, I noticed that too
    <teythoon> does gdb reparent the tracee?
    <hacklu_> I don't think this is a good behavior. gdb should get inferior's
      signal
    <teythoon> absolutely
    <hacklu_> In linux it does, not sure about hurd. but I think it should.
    <teythoon> definitively. there is proc_child in process.defs, but that may
      only be used once to set the parent of a process
    <hacklu_> gdb doesn't set the inferior as its child process if attached a
      running procss in HURD.

    <tschwinge> hacklu_: So you figured out this tracing/signal stuff.  Great!
    <hacklu_> tschwinge: Hi. not exactly. 
    <hacklu_> as I have mentioned,  gdb can't get signal when attach to a
      running process.
    <hacklu_> I also want to know how to build glibc in hurd. I have got this "
      relocation error: ./libc.so: symbol _dl_find_dso_for_object, version
      GLIBC_PRIVATE not defined in file ld.so.1 with link time reference" when
      use LD_PRELOAD=./my_build_glibc/libc.so 
    <tschwinge> hacklu: You can't just preload the new libc.so, but you'll also
      need to use the new ld.so.  Have a look at [glibc-build]/testrun.sh for
      how to invoke these properly.  Or, link with
      »-Wl,-dynamic-linker=[glibc-build]/elf/ld.so,-rpath,[glibc-build]:[glibc-build]/elf
      -L [glibc-build] -L [glibc-build]/elf«.  If using the latter, I suggest
      to also add »-Wl,-t« to verify that you're linking against the correct
      libraries, and »ldd
    <tschwinge> [executable]« to verify that [€xecutable] will load the correct
      libraries when invoked.
    <hacklu> I will try that, and I can't find this call
      pthread_cond_broadcast(). which will called in the proc_mark_stop 
    <tschwinge> hacklu: Oh, right, you'll also need to add libpthread (I think
      that's the directory name?) to the rpath and -L commands.
    <hacklu> is libpthread a part of glibc or hurd?
    <pinotree> glibc
    <NlightNFotis> hacklu: it is a different repository available here
      http://git.savannah.gnu.org/cgit/hurd/libpthread.git/
    <hacklu> tschwinge: thanks for that, but I don't think I need help about
      the comiler error now, it just say missing some C file. I will look into
      the Makefile to verify.
    <NlightNFotis> but I think it's a part of glibc as a whole
    <tschwinge> hacklu: OK.
    <tschwinge> glibc is/was a stand-alone package and library, but in Debian
      GNU/Hurd is nowadays integrated into glibc's build process.
    <hacklu> NlightNFotis: thanks. I only add hurd, glibc, gdb,mach code to my
      cscope file. seems need to add libpthread.
    <tschwinge> hacklu: If you use the Debian glibc package, our libpthread
      will be in the libpthread subdirectory.
    <tschwinge> Ignore nptl, which is used for the Linux kernel.
    <hacklu> tschwinge:BTW, I have found that, to continue the inferior from a
      breakpoint, doesn't need to call msg_sig_post_untraced. just call
      thread_abort and thread_resume is already ok.
    <hacklu> I get the glibc from http://git.savannah.gnu.org/cgit/hurd. 
    <tschwinge> hacklu: That sounds about right, because you want the inferior
      to continue normally, instead of explicitly sending a (Unix) signal to
      it.
    <tschwinge> hacklu: I suggest you use: »apt-get source eglibc« on your Hurd
      system.
    <tschwinge> hacklu: The Savannah repository does not yet have libpthread
      integrated.  I have this on my TODO list...
    <hacklu> tschwinge: no, apt-get source doesn't work in my Hurd. I got any
      code from git clone ***
    <pinotree> you most probably lack the deb-src entry in your sources.list
    <tschwinge> hacklu: Do you have deb-src lines in /etc/apt/source-list?  Or
      how does it fail?
    <hacklu> tschwinge: I have deb-src lines. and apt-get complain that: E:
      Unable to find a source package for eglibc or E: Unable to find a source
      package for glibc
    <youpi> hacklu: which deb-src lines do you have?
    <hacklu> and piece of my source_list : deb
      http://ftp.debian-ports.org/debian unreleased main deb-src
      http://ftp.debian-ports.org/debian unreleased main
    <youpi> you also need a deb-src line with the main archive
    <youpi> deb-src http://cdn.debian.net/debian unstable main
    <tschwinge> hacklu: Oh, hmm.  And you did run »apt-get update« before?
      That aside, there also is <http://snapshot.debian.org/package/eglibc/>
      that you can use.  You'll need the *.dsc and *.debian.tar.xz files
      corresponbding to your version of glibc, and the *.orig.tar.xz file.  And
      then run »dpkg-source -x *.dsc«.
    <tschwinge> The Debian snapshot is often very helpful if you need source
      packages that are no longer in the main Debian repository.
    <youpi> or simply running dget on the dsc url
    <tschwinge> Oh.  Good to know.
    <youpi> e.g. dget
      http://cdn.debian.net/debian/pool/main/e/eglibc/eglibc_2.17-7.dsc
    <hacklu> the network is slowly. and I am in apt-get update.
    <youpi> I will be away from this evening until sunday, too
    <hacklu> what the main difference between the source site?
    <hacklu> is dget means wget?
    <pinotree> no
    <hacklu> not exist in linux?
    <pinotree> it does, in devscripts
    <pinotree> it's a debian tool
    <hacklu> oh, yes, I have installed devscripts.
    <hacklu> I have got the libphread code, thanks.

    <braunr> teythoon: the simple fact that this msg thread exists to receive
      requests and that these requests are sent by ps and procfs is a potential
      DoS
    <teythoon> braunr: but does that mean that on Hurd a process can prevent a
      debugger from intercepting signals?
    <braunr> teythoon: yes
    <braunr> that's not a problem for interactive programs
    <braunr> it's part of the hurd design that programs have limited trust in
      each other
    <braunr> a user can interrupt his debugger if he sees no activity
    <braunr> that's more of a problem for non interactive system stuff like
      init scripts
    <braunr> or procfs
    <hacklu> why gdb can't get inferior's signal if attach a running process?
    <braunr> hacklu: try to guess
    <hacklu> braunr: it is not a reasonable thing. I always think it should
      catch the signal.
    <braunr> hacklu: signals are a unix thing built on top of mach
    <braunr> hacklu: think in terms of ports
    <braunr> all communication on the hurd goes through ports
    <hacklu> but when use gdb to start a process and debugg it, this way, gdb
      can catch the signal
    <braunr> hacklu: my guess is :
    <braunr> when starting a process, gdb can act as a proxy, much like
      rpctrace
    <braunr> when attaching, it can't 
    <hacklu> braunr: ah, my question should ask like this: why gdb can't set
      the inferior as its child process when attaching it? or it can not ?
    <braunr> hacklu: i'm not sure, the proc server is one of the parts i know
      the less
    <braunr> but again, i guess there is no facility to update the msg port of
      a process in the proc server
    <braunr> check that before taking it as granted
    <hacklu> braunr: aha, I alway think you know everything:)
    <tschwinge> braunr: There is: setmsgport or similar.
    <braunr> if there is one, gdb doesn't use it
    <tschwinge> hacklu: That is a good question -- I can't answer it off-hand,
      but it might be possible (by setting the tracing flag, and such things).
      Perhaps it's just a GDB bug, which omits to do that.  Perhaps just a
      one-line code change, perhaps not.  That's a new bug (?) report that we
      may want to have a look at later on.
    <tschwinge> hacklu: But also note, this new problem is not really related
      to your gdbserver work -- but of course you're fine to have a look at it
      if you'd like to.
    <hacklu> I just to ask for whether this is a normal behavior. this is
      related to my gdbserver work, as gdbserver also need to attach a running
      process...
    <braunr> gdbserver can start a process just like gdb does
    <braunr> you may want to focus on that first
    <tschwinge> Yes.
    <tschwinge> Attaching to processes that are already running is, I think,
      always more complicated compared to the case where GDB/gdbserver has
      complete control about the inferior right from the beginning.
    <hacklu> yes, I am  only focus on start one. the attach way I haven't
      research now.
    <tschwinge> hacklu: That's totally fine.  You can just say that attaching
      to processes is not supported yet.
    <hacklu> that's sound good:)
    <tschwinge> Ther will likely be more things in gdbserver that you won't be
      able to easily support, so it's fine to do it step-by-step.
    <tschwinge> And then later add more features incrementally.
    <tschwinge> That's also easier for reviewing the patches.

    <hacklu> and one more question I have ask yestoday. what is the rpctrace
      output (pid-1) mean?
    <tschwinge> hacklu: Another thing I can't tell off-hand.  I'll try to look
      it up.
    <teythoon> hacklu, tschwinge: my theory is that it is in fact an error
      message, maybe the proc server did not now a pid for the task
    <braunr> hacklu: utsl
    <hacklu> tschwinge: for saving your time, I will look the code myself, I
      don;t think this is a real hard question need you to help me by reading
      the source code.
    <tschwinge> teythoon, hacklu: Yes, from a quick inspection it looks like
      task2pid returning a -1 PID -- but I can't tell yet what that is supposed
      to mean, if it's an actualy bug, or just means there is no data
      available, or similar.
    <hacklu> braunr: utsl??
    <tschwinge> hacklu: http://www.catb.org/~esr/jargon/html/U/UTSL.html
    <hacklu> tschwinge: thank you. braunr like say abbreviation which I can't
      google out.
    <tschwinge> hacklu: Again, if this affects your work, it is fine to have a
      look at that presumed rpctrace problem, if not, it is fine to have a look
      at it if you'd like to, and otherwise, we'll file it as a possible bug to
      be looked at laster.
    <tschwinge> hacklu: Now you learned that one.  :-)
    <hacklu> tschwinge: ok , this doesn't affect me now. If I have time I will
      figure out it.

    <hacklu> how to understand the asyn RPC? 
    <braunr> hacklu: hm ?
    <hacklu> for instance, [hurd]/proc/main.c proc_server is loop in listening
      message. and handle it by message_demuxer.
    <hacklu> but when I send a request like proc_wait_request() to it, will it
      block in the message_demuxer?
    <hacklu> and where is the function of
      ports_manage_port_operations_multithread()?
    <braunr> this one is in libports
    <braunr> it's the last thing a server calls after bootstrapping itself
    <braunr> message_demuxer normally blocks, yes
    <braunr> but it's not "async"
    <hacklu> the names seems the proc_server is listening message with many
      threads?
    <braunr> every server in the hurd does
    <braunr> threads are created by ports_manage_port_operations_multithread
      when incoming messages can't be processed quick enough by the set of
      already existing threads
    <hacklu> if too many task send request to the server, will it ddos?
    <braunr> yes
    <teythoon> every server but /hurd/init
    <braunr> (and /hurd/hello)
    <braunr> hacklu: that's, in my opinion, a major design defect
    <hacklu> yes, that is reasonable.
    <braunr> that's what causes what i like to call thread storms on message
      floods ... :)
    <braunr> my hurd clone is intended to address such major issues
    <teythoon> couldn't that be migitated by some kind of heuristic?
    <braunr> it already is ..
    <hacklu> I don't image that the port_manage_port_operations_multithread
      will dynamically create threads. I thought the server will hang if all
      work thread is in use.
    <braunr> that would also be a major defect
    <braunr> creating as many threads as necessary is a good thing
    <braunr> the problem is the dos
    <braunr> hacklu: btw, ddos is "distributed" dos, and it doesn't really
      apply to what can happen on the hurd
    <hacklu> why not ? as far as I known, the message transport is
      transparent. hurd has the chance to be DDOSed
    <braunr> we don't care about the distributed property of the dos
    <hacklu> oh, I know what you mean.
    <braunr> it simply doesn't matter
    <braunr> on thread calling select in an event loop with a low timeout (high
      frequency) on a bunch of file descriptors is already enough to generate
      many dead-name notifications
    <tschwinge> Oh!  Based on what I've read in GDB source code, I thought the
      proc server was single-threaded.  However, it no longer is, after 1996's
      Hurd commit fac6d9a6d59a83e96314103b3181f6f692537014.
    <braunr> those notifications cause message flooding at servers (usually
      pflocal/pfinet), which spawn a lot of threads to handle those messages
    <braunr> one* thread
    <hacklu> tschwinge: ah, the comment in gnu_nat.c is out of date!
    <braunr> hacklu: and please, please, clean the hello_world processes you're
      creating on darnassus
    <braunr> i had to do it myself again :/
    <hacklu> braunr: [hacklu@darnassus ~]$ ps  ps: No applicable processes
    <braunr> ps -eflw
    <braunr> htop
    <tschwinge> hacklu: Probably the proc_wait_pid and proc_waits_pending stuff
      could be simplified then?  (Not an urgent issue, of course, will file as
      an improvement for later.)
    <hacklu> braunr: ps -eflw |grep hacklu
    <hacklu> 1038 12360 10746  26  26  2    87    22  148M 1.06M 97:21001   S
      p1  0:00.00 grep --color=auto hacklu
    <braunr> 15:08 < braunr> i had to do it myself again :/
    <teythoon> braunr: so as a very common special case, a lot of dead name
      notifications cause problems for pf*?
    <braunr> and use your numeric uid
    <braunr> teythoon: yes
    <hacklu> braunr: I am so sorry. I only used ps to check. forgive me
    <braunr> teythoon: simply put, a lot of messages cause problems
    <braunr> select is one special use case
    <teythoon> braunr: blocking other requests?
    <braunr> the other is page cache writeback
    <braunr> creating lots of threads
    <braunr> potentially deadlocking on failure
    <braunr> and in the case of writebacks, simply starving
    <teythoon> braunr: but dead name notifications should mostly trigger
      cleanup actions, couldn't those be handled by a different thread(pool)
      than the rest?
    <braunr> that's why you can bring down a hurd system with a simple cp
      bigfile somewhere, bigfile being a few hundreds MiBs
    <braunr> teythoon: it doesn't change the problem
    <braunr> threads are per task
    <braunr> and the contention would remain the same
    <teythoon> hm
    <braunr> since dead-name notifications are meant to release resources
      created by what would then be "regular" threads
    <braunr> don't worry, there is a solution
    <braunr> it's simple
    <braunr> it's well known
    <braunr> it's just hard to directly apply to the hurd
    <braunr> and impossible to enforce on mach
    <hacklu> tschwinge: I am confuzed after I have look into S_proc_wait()
      [hurd/proc/wait.c], it has relate pthread_hurd_cond_wait_np. I can't find
      out when it will return. And the signal is report to the debuger by
      S_proc_wait.
    <teythoon> braunr: a pointer please ;)
    <braunr> teythoon: basically, synchronous ipc
    <braunr> then, enforcing one server thread per client thread
    <braunr> and replace mach-generated notifications with messages sent from
      client threads
    <braunr> the only kind of notification required by the hurd are no-senders
      notifications
    <braunr> this happens when a client releases all references it has to a
      resource
    <braunr> so it's easy to make that synchronous as well
    <braunr> trying to design RPCs as closely as system calls on monolithic
      kernels helps in viewing how this works
    <braunr> the only real additions are address space crossing, and capability
      invocation
    <teythoon> sounds reasonable, why is it hard to apply to the hurd? most
      rpcs are synchonous, no?
    <braunr> mach ipc isn't
    <hacklu> braunr: When client C send a request to server S, but doesn't wait
      for the reply message right now, for a while, C call mach_msg to recieve
      reply. Can I think this is a synchronous RPC?
    <braunr> a malicious client can still overflow message queues
    <braunr> hacklu: no
    <teythoon> yes, I can see how this is impossible to enforce, but still we
      could all try to play nice :)
    <braunr> teythoon: no
    <braunr> :)
    <braunr> async ipc is heavy, error-prone, less performant than sync ipc
    <braunr> some async ipc is necessary to handle asynchronous events, but
      something like unix signals is actually a lot more appropriate
    <braunr> we're diverging from the gsoc though
    <braunr> don't waste too much time on that
    <teythoon> 15:13 < braunr> it's just hard to directly apply to the hurd
    <teythoon> I wont
    <teythoon> why is it hard
    <braunr> almost everything is synchronous on the hurd
    <braunr> except a few critical bits
    <braunr> signals :)
    <braunr> and select
    <braunr> and pagecache writebacks
    <braunr> fixing those parts require some work
    <braunr> which isn't trivial
    <braunr> for example, select should be rewritten not to use dead-name
      notifications
    <teythoon> adding a light weight signalling mechanism to mach and using
      that instead of async ipc?
    <braunr> instead of destroying ports once an event has been received, it
      should (synchyronously) remove the requests installed at remote servers
    <braunr> uh no
    <braunr> well maybe but that would be even harder
    <tschwinge> hacklu: This (proc/wait.c) is related to POSIX thread
      cancellation -- I don't think you need to be concerned about that.  That
      function's "real" exit points are earlier above.
    <braunr> teythoon: do you understand what i mean about select ?
    <teythoon> ^^ is that a no go area?
    <braunr> for now it is
    <braunr> we don't want to change the mach interface too much
    <teythoon> yes, I get the point about select, but I haven't looked at its
      implementation yet
    <hacklu> tschwinge: when I want to know the child task's state, I call
      proc_wait_request(), unless the child's state not change. the
      S_proc_wait() will not return?
    <braunr> it creates ports, puts them in a port set, gives servers send
      rights so they can notify about events
    <teythoon> y not? it's not that hurd is portable to another mach, or is it?
      and is there another that we want to be compatible with?
    <braunr> when an event occurs, all ports are scanned
    <braunr> then destroyed
    <braunr> on destruction, servers are notified by mach
    <braunr> the problem is that the client is free to continue and make more
      requests while existing select requests are still being cancelled
    <teythoon> uh, yeah, that sounds like a costly way of notifying somewone
    <braunr> the cost isn't the issue
    <braunr> select must do something like that on a multiserver system, you
      can't do much about it
    <braunr> but it should be synchronous, so a client can't make more requests
      to a server until the current select call is complete
    <braunr> and it shouldn't use a server approach at the client side
    <braunr> client -> server should be synchronous, and server -> client
      should be asynchronous (e.g. using a specific SIGSELECT signal like qnx
      does)
    <braunr> this is a very clean way to avoid deadlocks and denials of service
    <teythoon> yes, I see
    <braunr> qnx actually provides excellent documentation about these issues
    <braunr> and their ipc interface is extremely simple and benefits from
      decades of experience on the subject
    <tschwinge> hacklu: This function implements the POSIX wait call, and per
      »man 2 wait«: »The wait() system call suspends execution of the calling
      process until one of its children terminates.«
    <tschwinge> hacklu: This is implemented in glibc in sysdeps/posix/wait.c,
      sysdeps/unix/bsd/bsd4.4/waitpid.c, sysdeps/mach/hurd/wait4.c, by invoking
      this RPC synchronously.
    <tschwinge> hacklu: GDB on the other hand, uses this infrastructure (as I
      understand it) to detect (that is, to be informed) when a debuggee exits
      (that is, when the inferior process terminates).
    <tschwinge> hacklu: Ah, so maybe I miss-poke earlier: the
      pthread_hurd_cond_wait_np implements the blocking.  And depending on its
      return value the operation will be canceled or restarted (»start_over«).
    <tschwinge> s%maybe%%
    <tschwinge> hacklu: Does this information help?
    <hacklu> tschwinge: proc_wait_request is not only to detect the inferior
      exit. it also detect the child's state change
    <braunr> as tschwinge said, it's wait(2)
    <hacklu> tschwinge: and I have see this, when kill a signal to inferior,
      the gdb will get the message id=24120 which come from S_proc_wait
    <hacklu> braunr: man 2 wait says: wait, waitpid, waitid - wait for process
      to change state. (in linux, in hurd there is no man wait)
    <braunr> uh
    <braunr> there is, it's the linux man page :)
    <braunr> make sure you have manpages-dev installed
    <hacklu> I always think we are talk about linux's manpage :/
    <hacklu> but regardless the manpage, gdb really call proc_wait_request() to
      detect whether inferior's changed states
    <braunr> in any case, keep in mind the hurd is intended to be a posix
      system
    <braunr> which means you can always refer to what wait is expected to do
      from the posix spec
    <braunr> see
      http://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html
    <hacklu> braunr: even in the manpags under hurd, man 2 wait also says: wait
      for process to change state. 
    <braunr> yes
    <braunr> that's what it's for
    <braunr> what's the problem ?
    <hacklu> the problem is what tschwinge has said I don't understand. like
      and per »man 2 wait«: »The wait() system call suspends execution of the
      calling process until one of its children terminates.«
    <braunr> terminating is a form of state change
    <braunr> historically, wait was intended to monitor process termination
      only
    <hacklu> so the thread become stoped wait also return
    <braunr> afterwards, process tracing was added too
    <braunr> what ?
    <hacklu> so when the child state become stopped, the wait() call will
      return?
    <braunr> yes
    <hacklu> and I don't know this pthread_hurd_cond_wait_np. 
    <braunr> wait *blocks* until the process it references changes state
    <braunr> pthread_hurd_cond_wait_np is the main blocking function in hurd
      servers
    <braunr> well, pthread_hurd_cond_timedwait_np actually
    <braunr> all blocking functions end up there
    <braunr> (or in mach_msg)
    <braunr> (well pthread_hurd_cond_timedwait_np calls mach_msg too)
    <hacklu> since I use proc_wait_request to get the state change, so the
      thread in proc_server will be blocked, not me. is that right?
    <braunr> no
    <braunr> both
    <hacklu> this is just a request, why should block me?
    <braunr> because you're waiting for the reply afterwards
    <braunr> or at least, you should be
    <braunr> again, i'm not familiar with those parts
    <hacklu> after call proc_wait_request(), gdb does a lot stuffs, and then
      call mach_msg to recieve reply. 
    <braunr> ok
    <hacklu> I think it will be blocked only in mach_msg() if need.
    <braunr> usually, xxx_request are the async send-only versions of RPCs
    <tschwinge> Yes, that'S my understanding too.
    <braunr> and xxx_reply the async receive-only
    <braunr> so that makes sense
    <hacklu> so I have ask you is it a asyn RPC.
    <braunr> yes
    <braunr> 15:18 < hacklu> braunr: When client C send a request to server S,
      but doesn't wait for the reply message right now, for a while, C call
      mach_msg to recieve reply. Can I think this is a  synchronous RPC?
    <braunr> 15:19 < braunr> hacklu: no
    <braunr> if it's not synchronous, it's asynchronous
    <hacklu> sorry, I spell wrong. missing a 'a' :/
    <tschwinge> S_proc_wait_reply will then be invoked once the procserver
      actually answers the  "blocking" proc_wait call.
    <tschwinge> Putting "blocking" in quotes, because (due to the asyncoronous
      RPC invocation), GDB has not actually blocked on this.
    <braunr> well, it doesn't call proc_wait
    <hacklu> tschwinge: yes, the S_proc_wait_reply is called by
      process_reply_server(). 
    <hacklu> tschwinge: so the "blocked" one is the thread in proc_server .
    <tschwinge> braunr: Right.  »It requests the proc_wait service.«
    <braunr> gdb will also block on mach_msg
    <braunr> 16:05 < braunr> both
    <hacklu> braunr: yes, if gdb doesn't call mach_msg to recieve reply it will
      not be blocked.
    <braunr> i expect it will always call mach_msg
    <braunr> right ?
    <hacklu> braunr: yes, but before it call mach_msg, it does a lot other
      things. but finally will call mach_msg
    <braunr> that's ok
    <braunr> that's the kind of things asynchronous IPC allows
    <hacklu> tschwinge: I have make a mistake in my week report. The signal
      recive by inferior is notified by the proc_server, not the
      send_signal. Because the send_singal send a SIGCHLD to gdb's msgport not
      gdbself. That make sense.


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

    <hacklu> braunr: before I go to sleep last night, this question pop into my
      mind. How do you find my hello_world is still alive on darnassus? The
      process is not a CPU-heavy or IO-heavy guy. You will not feel any
      performance penalization. I am so curious :)
    <teythoon> hacklu: have you looked into patching the proc server to allow
      reparenting of processes?
    <hacklu> teythoon:not yet
    <teythoon> hacklu: i've familiarized myself with proc in the last week,
      this should get you started nicely: http://paste.debian.net/19985/
        diff --git a/proc/mgt.c b/proc/mgt.c
        index 7af9c1a..a11b406 100644
        --- a/proc/mgt.c
        +++ b/proc/mgt.c
        @@ -159,9 +159,12 @@ S_proc_child (struct proc *parentp,
           if (!childp)
             return ESRCH;
         
        +  /* XXX */
           if (childp->p_parentset)
             return EBUSY;
         
        +  /* XXX if we are reparenting, check permissions.  */
        +
           mach_port_deallocate (mach_task_self (), childt);
         
           /* Process identification.
        @@ -176,6 +179,7 @@ S_proc_child (struct proc *parentp,
           childp->p_owner = parentp->p_owner;
           childp->p_noowner = parentp->p_noowner;
         
        +  /* XXX maybe need to fix refcounts if we are reparenting, not sure */
           ids_rele (childp->p_id);
           ids_ref (parentp->p_id);
           childp->p_id = parentp->p_id;
        @@ -183,11 +187,14 @@ S_proc_child (struct proc *parentp,
           /* Process hierarchy.  Remove from our current location
              and place us under our new parent.  Sanity check to make sure
              parent is currently init. */
        -  assert (childp->p_parent == startup_proc);
        +  assert (childp->p_parent == startup_proc); /* XXX */
           if (childp->p_sib)
             childp->p_sib->p_prevsib = childp->p_prevsib;
           *childp->p_prevsib = childp->p_sib;
         
        +  /* XXX we probably want to keep a reference to the old
        +     childp->p_parent around so that if the debugger dies or detaches,
        +     we can reparent the process to the old parent again */
           childp->p_parent = parentp;
           childp->p_sib = parentp->p_ochild;
           childp->p_prevsib = &parentp->p_ochild;
    <teythoon> the code doing the reparenting is already there, but for now it
      is only allowed to happen once at process creation time
    <hacklu> teythoon: good job. This is in my todo list, when I implement
      attach feature to gdbserver I will need this 
    <braunr> hacklu: i use htop
    <teythoon> braunr: why is that process so disruptive?
    <braunr> the big problem with those stale processes is that they're in a
      state that prevents one important script to complete
    <braunr> there is a bug on the hurd with regard to terminals
    <braunr> when you log out of an ssh session, the terminal remains open for
      some reason (bad reference counting somewhere, but it's quite tricky to
      identify)
    <braunr> to work around the issue, i have a cron job that calls a script to
      kill unused terminals
    <braunr> this works by listing processes
    <braunr> your hello_world processes block that listing
    <teythoon> uh, how so?
    <hacklu> braunr: ok. I konw. 
    <braunr> teythoon: probably the denial of service we were talking about
      yesterday
    <teythoon> select flooding a server?
    <braunr> no, a program refusing to answer on its msg port
    <braunr> ps has an option -M :
    <braunr>   -M, --no-msg-port          Don't show info that uses a process's
      msg port
    <braunr> the problem is that my script requires those info
    <teythoon> ah, I see, right
    <braunr> hacklu being working on gdb, it's not surprising he's messing with
      that
    <teythoon> yes indeed. couldn't ps use a timeout to detect that?
    <hacklu> braunr: yes, once I have found ps will hang when I has run
      hello_world in a breakpoint state.
    <teythoon> braunr: thanks for explaining the issue, i always wondered why
      that process is such big a deal ;)
    <braunr> teythoon: how do you tell between processes being slow to answer
      and intentionnally refusing to answer ?
    <braunr> a timeout is almost never the right solution
    <braunr> sometimes it's the only solution though, like for networking
    <braunr> but on a system running on a local machine, there is usually
      another way
    <teythoon> braunr: I don't of course
    <braunr> ?
    <braunr> ah ok
    <braunr> it was rethorical :)
    <teythoon> yes I know, and I was implying that I wasn't expecting a timeout
      to be the clean solution
    <teythoon> and the current behaviour is hardly acceptable
    <braunr> i agree
    <braunr> it's ok for interactive cases
    <braunr> you can use Ctrl-C, which uses a 3 seconds delay to interrupt the
      client RPC if nothing happens
    <teythoon> braunr: btw, what about *_reply.defs? Should I add a
      corresponding reply simpleroutine if I add a routine?
    <braunr> normally yes
    <braunr> right, forgot about that
    <teythoon> so that the procedure ids are kept in sync in case one wants to
      do this async at some point in the future?
    <braunr> yes
    <braunr> this happened with select
    <braunr> i had to fix the io interface
    <teythoon> ok, noted


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

    <hacklu> Do we need write any other report for the mid-evaluation? I have
      only submit a question-answer to google.


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

    <hacklu> hi, this is my weekly
      report. http://hacklu.com/blog/gsoc-weekly-report7build-gdbserver-on-gnuhurd-164/
    <hacklu> youpi: can you show me some suggestions about how to design the
      interface and structure of gdbserver?
    <youpi> hacklu: well, I've read your blog entry, I was wondering about
      tschwinge's opinion, that's why I asked whether he was here
    <youpi> I would tend to start from an existing gdbserver, but as I haven't
      seen the code at all, I don't know how much that can help
    <hacklu> so you mean I shoule get a worked gdbserver then to improve it?
    <youpi> I'd say so, but again it's not a very strong opinion
    <youpi> I'd rather let tschwinge comment on this
    <hacklu> youpi: ok :)


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

    <hacklu> hi, this is my weekly report
      http://hacklu.com/blog/gsoc-weekly-report8-168/ . sorry for so late.

    <youpi> hacklu: it seems we misunderstood ourselves last week, I meant to
      start from the existing gdbserver implementation
    <youpi> but never mind :)
    <youpi> starting from the lynxos version was a good idea
    <hacklu> youpi: em... yeah, the lynxos port is so clean and simple.

    <hacklu> youpi: aha, the "Remote connection closed" problem has been fixed
      after I add a init_registers_i386() and set the structure target_desc.
    <hacklu> but I don't get understand with the structure target_desc. I only
      know it is auto-generated which configured by the configure.srv.
    <tschwinge> Hi!
    <tschwinge> hacklu: In gdbserver, you should definitely re-use existing
      infrastructure, especially anything that deals with the
      protocol/communication with GDB (that is, server.c and its support
      files).
    <tschwinge> hacklu: Then, for the x86 GNU Hurd port, it should be
      implemented in the same way as an existing port.  The Linux port is the
      obvious choice, of course, but it is also fine to begin with something
      simpler (like the LynxOS port you've chosen), and then we can still add
      more features later on.  That is a very good approach actually.
    <tschwinge> hacklu: The x86 GNU Hurd support will basically consist of
      three pieces -- exactly as with GDB's native x86 GNU Hurd port: x86
      processor specific (tge existing gdbserver/i386-low.c etc. -- shouldn't
      need any modifications (hopefully)), GNU Hurd specific
      (gdbserver/gnu-hurd-low.c (or similar)), and x86 GNU Hurd specific
      (gdbserver/gnu-hurd-x86-low.c (or similar)).
    <tschwinge> s%tge%the
    <hacklu> tschwinge: now I have only add a file named gnu-low.c, I should
      move some part to the file gnu-i386-low.c I think.
    <tschwinge> hacklu: That's fine for the moment.  We can move the parts
      later (everything with 86 in its name, probably).
    <hacklu> that's ok.
    <hacklu> tschwinge: Can I copy code from gnu-nat.c to
      gdbserver/gnu-hurd-low.c? I think the two file will have many same code.
    <tschwinge> hacklu: That's correct.  Ideally, the code should be shared
      (for example, in a file in common/), but that's an ongoing discussion in
      GDB, for other duplicated code.  So, for the moment, it is fine to copy
      the parts you need.
    <tschwinge> hacklu: Oh, but it may be a good idea to add a comment to the
      source code, where it is copied from.
    <hacklu> maybe I can do a common-part just for hurd gdb port.
    <tschwinge> That should make it easier later on, to consolidate the
      duplicated code into one place.
    <tschwinge> Or you can do that, of course.  If it's not too difficult to
      do?
    <hacklu> I think at the begining it is not difficult. But when the
      gdbserver code grow, the difference with gdb is growing either. That will
      be too many #if else.
    <tschwinge> I think we should check with the GDB maintainers, what they
      suggest.
    <tschwinge> hacklu: Please send an email To: <gdb@sourceware.org> Cc:
      <lgustavo@codesourcery.com>, <thomas@codesourcery.com>, and ask about
      this: you need to duplicate code that already exists in gnu-nat.c for new
      gdbserver port -- how to share code?
    <hacklu> tschwinge: ok, I will send the email right now.
    <hacklu> tschwinge: need I cc to hurd mail-list?
    <tschwinge> hacklu: Not really for that questions, because that is a
      question only relevant to the GDB source code itself.
    <hacklu> tschwinge: got it.

[[!message-id
"CAB8fV=jzv_rPHP3-HQVBA-pCNZNat6PNbh+OJEU7tZgQdKX3+w@mail.gmail.com"]].


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

<http://hacklu.com/blog/gsoc-weekly-report9-172/>.

    <hacklu__> when and where is the best time and place to get the regitser
      value in gdb?
    <youpi> well, I'm not sure to understand the question
    <youpi> you mean in the gdb source code, right?
    <youpi> isn't it already done in gdb?
    <youpi> probably similarly to i386?
    <youpi> (linux i386 I mean)
    <hacklu__> I don't find the fetch_register or relate function implement in
      gnu-nat.c 
    <hacklu__> so I can't make decision how to implement this in gdbserver.
    <youpi> it's in i386gnu-nat.c, isn't it?
    <hacklu__> yeah.
    <youpi> does that answer your issue?
    <hacklu__> thank you. I am so stupid


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

    < hacklu> hello everyone, this is my week
      report. http://hacklu.com/blog/gsoc-weekly-report10-174/

    < hacklu> but now I face a new problem, when I typed the first continue
      command, gdb will continue all the breakpoint, and the inferior will run
      until normally exit.


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

    <hacklu> tschwinge: hi, does gdb's attach feature work correctlly on Hurd? 
    <hacklu> on my hurd-box, the gdb can't attach to a running process, after a
      attaching, when I continue, gdb complained "can't find pid 12345"
    <teythoon> hacklu: attaching works, not sure why gdb is complaining
    <hacklu> teythoon: yeah, it can attaching, but can't contine process. 
    <hacklu> in this case, the debugger is useless if it can't resume execution
    <teythoon> hacklu: well, gdb on Linux reacts a little differently, but for
      me attaching and then resuming works
    <hacklu> teythoon: yes, gdb on linux works well.
    <teythoon> % gdb --pid 21506 /bin/sleep
    <teythoon> [...]
    <teythoon> (gdb) c
    <teythoon> Continuing.
    <teythoon> warning: Can't wait for pid 21506: No child processes
    <teythoon> # pkill -SIGILL sleep
    <teythoon> warning: Pid 21506 died with unknown exit status, using SIGKILL.
    <hacklu> yes. I used a sleep program to test too.
    <teythoon> I believe that the warning and deficiencies with the signal
      handling are b/c on Hurd the debuggee cannot be reparented to the
      debugger
    <hacklu> oh, I remembered, I have asked this before.
    <tschwinge> Confirming that attaching to a process in __sleep -> __mach_msg
      -> mach_msg_trap works fine, but then after »continue«, I see »warning:
      Can't wait for pid 4038: No child processes« and three times »Can't fetch
      registers from thread bogus thread id 1: No such thread« and the sleep
      process exits (normally, I guess? -- interrupted "system call").
    <tschwinge> If detaching (exit GDB) instead, I see »warning: Can't modify
      tracing state for pid 4041: No such process« and the sleep process exits.
    <tschwinge> Attaching to and then issueing »continue« in a process that is
      not currently in a mach_msg_trap (tested a trivial »while (1);«) seems to
      work.
    <tschwinge> hacklu: ^
    <hacklu> tschwinge: in my hurdbox, if I just attach a while(1), the system
      is near down. nothing can happen, maybe my hardware is slow.
    <hacklu> so I can only test on the sleep one.
    <hacklu> my gdbserver doesn't support attach feature now. the other basic
      feather has implement. I am doing test and review the code now.
    <tschwinge> Great!  :-)
    <tschwinge> It is fine if attaching does not work currently -- can be added
      later.
    <hacklu> btw, How can I submit my code? put the patch in email directly?
    <tschwinge> Did you already run the GDB testsuite using your gdbserver?
    <hacklu> no, haven't yet
    <tschwinge> Either that, or a Git branch to pull from.
    <hacklu> I think I should do more review and test than I submit patches.
    <tschwinge> hacklu: See [GDB]/gdb/testsuite/boards/native-gdbserver.exp
      (and similar files) for how to run the GDB testsuite with gdbserver.
    <hacklu> ok. 
    <tschwinge> But don't be disappointed if there are still a lot of failures,
      etc.  It'll already be great if some basic stuff works.
    <hacklu> now it can set and remove breakpoint. show register, access
      variables.
    <tschwinge> ... which already is enogh for a lot of debugging sessions.
      :-)
    <hacklu> I will continue to make it more powerful.
    <hacklu> :)
    <tschwinge> Yes, but please first work on polishing the existing code, and
      get it integrated upstream.  That will be a great milestone.
    <tschwinge> No doubt that GDB maintainers will have lots of comments about
      proper formatting of the source code, and such things.  Trivial, but will
      take time to re-work and get right.
    <hacklu> oh, I got it. I will give my pathch before this weekend.
    <tschwinge> Then once your basic gdbserver is included, you can continue to
      implement additional features, piece by piece.
    <tschwinge> And then we can run the GDB testsuite with gdbserver and
      compare that there are no regressions, etc.
    <tschwinge> Heh, »before the weekend« -- that's soon.  ;-)
    <hacklu> honestly to say, most of the code is copyed from other files, I
      haven't write too many code myself.
    <tschwinge> Good -- this is what I hoped.  Often, more time in software
      development is spent on integrating existing things rathen than writing
      new code.
    <hacklu> but I have spent a lot of time to get known the code and to debug
      it to work.
    <tschwinge> Thzis is normal, and is good in fact: existing code has already
      been tested and documented (in theory, at least...).
    <tschwinge> Yes, that's expected too: when relying on/reusing existing
      code, you first have to understand it, or at least its interfaces.  Doing
      that, you're sort of "mentally writing the existing code again".
    <tschwinge> So, this sounds all fine.  :-)
    <hacklu> your words make me happy.
    <hacklu> :)
    <tschwinge> Well, I am, because this seems to be going well.
    <hacklu> thank you. I am going to coding now~~


# IRC, freenode, #hurd, 2013-09-02

    <hacklu> hi, this is my weekly
      report. http://hacklu.com/blog/gsoc-weekly-report11-181/

    <hacklu> please give me any advice on how to use mig to generate stub-files
      in gdbserver? 
    <braunr> hacklu:
      http://darnassus.sceen.net/gitweb/rbraun/slabinfo.git/blob/HEAD:/Makefile
    <hacklu> braunr: shouldnt' I work like this
      https://github.com/hacklu/gdbserver/blob/gdbserver/gdb/config/i386/i386gnu.mh
      ?
    <braunr> hacklu: seems that you need server code
    <braunr> other than that i don't see the difference
    <hacklu> gdb use autoconf to generate the Makefile, and part from the *.mh
      file, but in gdbserver, there is no .mh like files.
    <braunr> hacklu: why can't you reuse /i386gnu.mh ?
    <hacklu> braunr: question is that, there are something not need in
      /i386gnu.mh.
    <braunr> hacklu: like what ?
    <hacklu> braunr: like fork-child.o msg_U.o core-regset.o
    <braunr> hacklu: well, adjust the dependencies as you need
    <braunr> hacklu: do you mean they become useless for gdbserver but are
      useful for gdb ?
    <hacklu> braunr: yes, so I need another one gnu.mh file.
    <hacklu> braunr: but the gdbserver's configure doesn't have any *.mh file,
      can I add the first one? 
    <braunr> or adjust the values of those variables depending on the building
      mode
    <braunr> maybe
    <braunr> tschwinge is likely to better answer those questions
    <hacklu> braunr: ok, I will wait for tschwinge's advice.
    <luisgpm> hacklu, The gdb/config/ dir is for files related to the native
      gdb builds, as opposed to a cross gdb that does not have any native bits
      in it. In the latter, gdbserver will be used to touch the native layer,
      and GDB will only guide gdbserver through the debugging session...
    <luisgpm> hacklu, In case you haven't figured that out already.
    <hacklu> luisgpm: I am not very clear with you. According to your words, I
      shouldn't use gdb/config for gdbserver? 
    <luisgpm> hacklu, Correct. You should use configure.srv for gdbserver.
    <luisgpm> hacklu, gdb/gdbserver/configure.srv that is.
    <luisgpm> hacklu, gdb/configure.tgt for non-native gdb files...
    <luisgpm> hacklu, and gdb/config for native gdb files.
    <luisgpm> hacklu, The native/non-native separation for gdb is due to the
      possibility of having a cross gdb.
    <congzhang> what's srv file purpose?
    <luisgpm> hacklu, gdbserver, on the other hand, is always native.
    <luisgpm> Doing the target-to-object-files mapping.
    <hacklu> how can I use configure.srv to config the MIG to generate
      stub-files?
    <luisgpm> What are stub-files in this context?
    <hacklu> On Hurd, some rpc stub file are auto-gen by MIG with *.defs file
    <braunr> luisgpm: c source code handling low level ipc stuff
    <braunr> mig is the mach interface generator
    <tschwinge> luisgpm, hacklu: If that is still helpful by now, in
      <http://news.gmane.org/find-root.php?message_id=%3C87ppwqlgot.fsf%40kepler.schwinge.homeip.net%3E>
      I described the MIG usage in GDB.  (Which also states that ptrace is a
      system call which it is not.)
    <tschwinge> hacklu: For the moment, it is fine to indeed copy the rules
      related to MIG/RPC stubs from gdb/config/i386/i386gnu.mh to a (possibly
      new) file in gdbserver.  Then, later, we should work out how to properly
      share these, as with all the other code that is currently duplicated for
      GDB proper and gdbserver.
    <luisgpm> hacklu, tschwinge: If there is code gdbserver and native gdb can
      use, feel free to put them inside gdb/common for now.
    <tschwinge> hacklu, luisgpm: Right, that was the conclusion from
      <http://news.gmane.org/find-root.php?message_id=%3CCAB8fV%3Djzv_rPHP3-HQVBA-pCNZNat6PNbh%2BOJEU7tZgQdKX3%2Bw%40mail.gmail.com%3E>.
    <hacklu> tschwinge, luisgpm : ok, I got it.
    <hacklu> tschwinge: sorry for haven't submit pathes yet, I will try to
      submit my patch tomorrow.

[[!message-id "CAB8fV=iw783uGF8sWyqJNcWR0j_jaY5XO+FR3TyPatMGJ8Fdjw@mail.gmail.com"]].


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

    <hacklu> If I want compile a file which is not in the current directory,
      how should I change the Makefile. I have tried that obj:../foo.c, but the
      foo.o will be in ../, not in the current directory.
    <hacklu> As say, When I build gdbserver, I want to use [gdb]/gdb/gnu-nat.c,
      How can I get the gnu-nat.o under gdbserver's directory?
    <hacklu> tschwinge: ^^
    <tschwinge> Hi!
    <tschwinge> hacklu: Heh, unexpected problem.
    <tschwinge> hacklu: How is this handled for the files that are already in
      gdb/common/?  I think these would have the very same problem?
    <hacklu> tschwinge: ah. 
    <hacklu> I got it
    <tschwinge> I see, for example:
    <tschwinge> ./gdb/Makefile.in:linux-btrace.o:
      ${srcdir}/common/linux-btrace.c
    <tschwinge> ./gdb/gdbserver/Makefile.in:linux-btrace.o:
      ../common/linux-btrace.c $(linux_btrace_h) $(server_h)
    <hacklu> If I have asked before, I won't use soft link to solve this.
    <tschwinge> But isn't that what you've been trying?
    <hacklu> when this, where the .o file go to?
    <tschwinge> Yes, symlinks can't be used, because they're not available on
      every (file) system GDB can be built on.
    <tschwinge> I would assume the .o files to go into the current working
      directory.
    <tschwinge> Wonder why this didn't work for you.
    <hacklu> in gdbserver/configure.srv, there is a srv_tgtobj="gnu_nat.c ..",
      if I change the Makefile.in, it doesn't gdb's way.
    <hacklu> So I can't use the variable srv_tgtobj? 
    <tschwinge> That should be srv_tgtobj="gnu_nat.o [...]"?  (Not .c.)
    <hacklu> I have try this, srv_tgtobj="../gnu_nat.c", then the gnu_nat.o is
      generate in the parent directory. 
    <hacklu> s/.c/.o
    <hacklu> (wrong input)
    <hacklu> For my understand now, I should set the srv_tgtobj="", and then
      set the gnu_nat.o:../gnu_nat.c in the gdbserver/Makefile.in. right?
    <tschwinge> Hmm, I thought you'd need both.
    <tschwinge> Have you tried that?
    <hacklu> no, haven't yet. I will try soon.
    <hacklu> I have met an strange thing. I have this in Makefile,
      i386gnu-nat.o:../i386gnu-nat.c $(CC) -c $(CPPFLAGS) $(INTERNAL_CFLAGS) $<
    <hacklu> When make, it will complain that: no rules for target
      i386gnu-nat.c 
    <hacklu> but I also have a line gnu-nat.o:../gnu-nat.c ../gnu-nat.h. this
      works well.
    <tschwinge> hacklu: Does it work if you use $(srcdir)/../i386gnu-nat.c
      instead of ../i386gnu-nat.c?
    <tschwinge> Or similar.
    <hacklu> I have try this, i386gnu-nat.c: echo "" ; then it works.
    <hacklu> (try $(srcdir) ing..)
    <hacklu> make: *** No rule to make target `.../i386gnu-nat.c', needed by
      `i386gnu-nat.o'.  Stop.
    <hacklu> seems no use.
    <hacklu> tschwinge: I have found another thing, if I rename the
      i386gnu-nat.o to other one, like i386gnu-nat2.o. It works!


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

    <hacklu> hi, I have found many '^L' in gnu-nat.c, should I fix it or keep
      origin? 
    <LarstiQ> hacklu: fix in what sense?
    <hacklu> remove the line contains ^L
    <LarstiQ> hacklu: see bottom of
      http://www.gnu.org/prep/standards/standards.html#Formatting
    <LarstiQ> hacklu: "Please use formfeed characters (control-L) to divide the
      program into pages at logical places (but not within a function)."
    <LarstiQ> hacklu: so unless a reason has come up to deviate from the gnu
      coding standards, those ^L's are there by design
    <hacklu> LarstiQ: Thank you! I always think that are some format error. I
      am stupid.
    <LarstiQ> hacklu: not stupid, you just weren't aware
    * LarstiQ thought the same when he first encountered them


# IRC, freenode, #hurd, 2013-09-09

    <youpi> hacklu_, hacklu__: I don't know what tschwinge thinks, but I guess
      you should work with upstream on integration of your existing work, this
      is part of the gsoc goal: submitting one's stuff to projects
    <tschwinge> youpi: Which is what we're doing (see the patches recently
      posted).  :-)
    <youpi> ok
    <hacklu__> youpi: I always doing what you have suggest. :)
    <hacklu> I have asked in my new mail, I want to ask at here again.  Should
      I change the gdb use lwp filed instead of tid field? There are 
    <hacklu> too many functions use tid. Like
    <hacklu> named tid in the structure proc also.
    <hacklu> make_proc(),inf_tid_to_thread(),ptid_build(), and there is a field
    <hacklu> (sorry for the bad \n )
    <hacklu> and this is my weekly
      report. http://hacklu.com/blog/gsoc-weekly-report12-186/
    <hacklu> And in Pedro Alves's reply, he want me to integration only one
      back-end for gdb and gdbserver. but the struct target_obs are just
      decalre different in both of the two. How can I integrate this? or I got
      the mistaken understanding?
    <hacklu> tschwinge: ^^
    <tschwinge> hacklu: I will take this to email, so that Pedro et al. can
      comment, too.
    <tschwinge> hacklu: I'm not sure about your struct target_ops question.
      Can you replay to Pedro's email to ask about this?
    <hacklu> tschwinge: ok.
    <tschwinge> hacklu: I have sent an email about the LWP/TID question.
    <hacklu> tschwinge: Thanks for your email, now I know how to fix the
      LWP/TID for this moment.
    <tschwinge> hacklu: Let's hope that Pedro also is fine with this.  :-)
    <hacklu> tschwinge: BTW, I have a question, if we just use a locally
      auto-generated number to distignuish threads in a process, How can we do
      that?
    <hacklu> How can we know which thread throwed the exception?
    <hacklu> I haven't thought about this before.
    <tschwinge> hacklu: make_proc sets up a mapping from Mach threads to GDB's
      TIDs.  And then, for example inf_tid_to_thread is used to look that up.
    <hacklu> tschwinge: oh, yeah. that is.


# IRC, freenode, #hurd, 2013-09-16

    <tschwinge> hacklu: Even when waiting for Pedro (and me) to comment, I
      guess you're not out of work, but can continue in parallel with other
      things, or improve the patch?
    <hacklu> tschwinge: honestly to say, these days I am out of work T_T after
      I have update the patch.
    <hacklu> I am not sure how to improve the patch beyond your comment in the
      email. I have just run some testcase and nothing others.
    <tschwinge> hacklu: I have not yet seen any report on the GDB testsuite
      results using your gdbserver port (see
      gdb/testsuite/boards/native-gdbserver.exp).  :-D
    <hacklu> question is, the resule of that testcase is just how many pass how
      many not pass.
    <hacklu> and I am not sure whether need to give this information.
    <tschwinge> Just as a native run of GDB's testsuite, this will create *.sum
      and *.log files, and these you can diff to those of a native run of GDB's
      testsuite.
    <hacklu> https://paste.debian.net/41066/ this is my result
     === gdb Summary ===
    
    # of expected passes            15573
    # of unexpected failures        609
    # of unexpected successes       1
    # of expected failures          31
    # of known failures             57
    # of unresolved testcases       6
    # of untested testcases         47
    # of unsupported tests          189
    /home/hacklu/code/gdb/gdb/testsuite/../../gdb/gdb version  7.6.50.20130619-cvs -nw -nx -data-directory /home/hacklu/code/gdb/gdb/testsuite/../data-directory
    
    make[3]: *** [check-single] Error 1
    make[3]: Leaving directory `/home/hacklu/code/gdb/gdb/testsuite'
    make[2]: *** [check] Error 2
    make[2]: Leaving directory `/home/hacklu/code/gdb/gdb'
    make[1]: *** [check-gdb] Error 2
    make[1]: Leaving directory `/home/hacklu/code/gdb'
    make: *** [do-check] Error 2
    <hacklu> I got a make error so I don't get the *.sum and *.log file. 
    <tschwinge> Well, that should be fixed then?
    <tschwinge> hacklu: When does university start again for you?
    <hacklu> My university have start a week ago.
    <hacklu> but I will fix this,
    <tschwinge> Oh, OK.  So you won't have too much time anymore for GDB/Hurd
      work?
    <hacklu> it is my duty to finish my work. 
    <hacklu> time is not the main problem to me, I will shedule it for myself.
    <tschwinge> hacklu: Thanks!  Of course, we'd be very happy if you stay with
      us, and continue working on this project (or another one)!  :-D
    <hacklu> I also thanks all of you who helped me and mentor me to improve
      myself.
    <hacklu> then, what the next I can do is that fix the testcase failed? 
    <tschwinge> hacklu: It's been our pleasure!
    <tschwinge> hacklu: A comparison of the GDB testsuite results for a native
      and gdbserver run would be good to get an understanding of the current
      status.
    <hacklu> ok, I will give this comparison soon. BTW,should I compare the
      native gdb result with the one before my patch
    <tschwinge> You mean compare the native run before and after your patch?
      Yes, that also wouldn't hurt to do, to show that your patch doesn't
      introduce any regressions to the native GDB port.
    <hacklu> ok, beside this I should compare the native gdb with gdbserver ?
    <tschwinge> Yes.
    <hacklu> beside this, what I can do more? 
    <tschwinge> No doubt, there will be differences between the native and
      gdbserver test runs -- the goal is to reduce these.  (This will probably
      translate to: implement more stuff for the Hurd port of gdbserver.)
    <hacklu> ok, I know it. Start it now
    <tschwinge> As time permits.  :-)
    <hacklu> It's ok. :)


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

    <hacklu_> I have to go out in a few miniutes, will be back at 8pm. I am
      sorry to miss the meeting this week, I will finishi my report soon. 
    <hacklu_> tschwinge, youpi ^^