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

<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 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
  https://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 https://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.ports.debian.org/debian-ports unreleased main deb-src
  http://ftp.ports.debian.org/debian-ports 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.

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:
  https://darnassus.sceen.net/cgit/rbraun/slabinfo.git/plain/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.

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 ^^