[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
# 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
<hacklu> braunr: things goes more hard than I think, these are some
differences between ptrace() on Hurd and Linux. I am trying to solve
# IRC, freenode, #hurd, 2013-06-24
<hacklu> this is my weekly report
<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> 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
<hacklu> youpi: how gnu_wait pass one message to exc_server? in which
<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
<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
<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
<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
<tschwinge> This also has some explanation of the thread/task's exception
<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
<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:
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
<hacklu> iirc ?
<braunr> if i recall cl=orrectly
<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
<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,
<braunr> hacklu: see hurd/msg.defs for the msg interface (which handles
<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
<braunr> (finding the right server function is done by these demux
<braunr> hacklu: see hurd/msgportdemux.c in glibc to see how it's done
<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
<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...)
<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.
<hacklu> and the notify_server code is generater by mig automatically.
# IRC, freenode, #hurd, 2013-06-29
<hacklu> I just failed to build the demo on
<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
<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
<hacklu> if exist a task to do the work, why we need this thread?
<braunr> this thread is the "task"
<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> 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
<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
<braunr> on the hurd, only the second thread of a task receives exception
<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> 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
<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.
<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 ?
<braunr> which one ?
When an exception occurs in a thread, the thread sends an exception
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)
port, using the exc_serverfunction to decode the messages and then
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> 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> 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> 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> 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
<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> 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?
<hacklu> so, the proc server handles the exceptions throwed by the msg
<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
# IRC, freenode, #hurd, 2013-07-01
<hacklu> hi. this is my weekly
report. http://hacklu.com/blog/gsoc-weekly-report2-124/ welcome to any
<hacklu> teythoon: I only get clear about the rpc stuff. seems a lot behind
<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> 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.
<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> 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
<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.
<nlightnfotis> do process own any ports? or are all their ports associated
with the process server?
<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> 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
In context of [[open_issues/libpthread/t/fix_have_kernel_resources]]:
<braunr> hacklu: if you ever find out about either glibc or the proc server
creating one receive right for each thread, please let me know
# IRC, freenode, #hurd, 2013-07-07
<hacklu> how fork() goes?
<pinotree> see sysdeps/mach/hurd/fork.c in glibc' sources
<hacklu> when the father has two thread( main thread and the signal thead),
if the father call fork, then the child inmediatelly call exev() to
change the excute file. how many thread in the children?
<hacklu> For instance, the new execute file also have two thread.
<hacklu> will the exev() destroyed two threads and then create two new?
<hacklu> s/exev()/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
<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
<hacklu> thanks, I have found that.
# IRC, freenode, #hurd, 2013-07-08
<hacklu> hi, this is my weekly
<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
<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:
»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
<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
<tschwinge> hacklu: That's how I found it, yes.
<hacklu> tschwinge: :)