diff options
Diffstat (limited to 'community/gsoc/2013/hacklu.mdwn')
| -rw-r--r-- | community/gsoc/2013/hacklu.mdwn | 2099 |
1 files changed, 2099 insertions, 0 deletions
diff --git a/community/gsoc/2013/hacklu.mdwn b/community/gsoc/2013/hacklu.mdwn new file mode 100644 index 00000000..b7de141b --- /dev/null +++ b/community/gsoc/2013/hacklu.mdwn @@ -0,0 +1,2099 @@ +[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2013-06-23 + + <hacklu> braunr: sorry for the late reply. Honestly to say, the school + works had taken most of my time these days. I haven't got any + siginificant progress now. I am trying to write a little debugger demo on + Hurd. + <hacklu> braunr: things goes more hard than I think, these are some + differences between ptrace() on Hurd and Linux. I am trying to solve + this. + + +# IRC, freenode, #hurd, 2013-06-24 + + <hacklu> this is my weekly report + http://hacklu.com/blog/gsoc-weekly-report1-117/. + <hacklu> and I have two main questions when I read the gdb source code. + <hacklu> 1/What is the S_exception_raise_request()? 2/what is the role of + ptrace in gdb port on Hurd? + <youpi> hacklu: where did you see S_exception_raise_request? + <hacklu> in gdb/gnu-nat.c + <youpi> ah, in gdb + <hacklu> yeah. and I have read the <The hurd hacking guide>. is says the S_ + start means server stub. + <youpi> yes + <youpi> what happens is that gnu_wait keeps calling mach_msg + <youpi> to get a message + <youpi> then it passes that message to the various stubs servers + <youpi> see just below, it calls exc_server, among others + <youpi> and that's exc_server which ends up calling + S_exception_raise_request, if the message is an exception_raise request + <youpi> exc_server is a mere multiplexer, actually + <tschwinge> S_exception_raise_request is the implementation of the request + part (so one half of a typical RPC) of the Mach exception interface. + <tschwinge> See gdb/exc_request.defs in GDB and include/mach/exc.defs in + Mach. + <hacklu> youpi: how gnu_wait pass one message to exc_server? in which + function? + <youpi> in gnu_wait() + <youpi> && !exc_server (&msg.hdr, &reply.hdr) + <hacklu> oh, I see this. + <hacklu> firstly I think it is a type check simply. + <youpi> see the comment: "handle what we got" + <tschwinge> The Hurd's proc server also is involved in the exception + passing protocol (see its source code). + <hacklu> tschwinge: I will check the source code later. is the exception + take place in this way: 1. the inferior call ptrace(TRACE_ME). 2.the gdb + call task_set_exception_port. 3. mach send a notification to the + exception port set before. 4. gdb take some action. + <tschwinge> hacklu: Yes, that's it, roughly. The idea is that GDB replaces + a process' standard exception port, and replaces it "with itself", so + that when the process that is debugged receives and exception (by Mach + sending a exception_raise RPC), GDB can then catch that and act + accordingly. + <tschwinge> hacklu: As for your other questions, about ptrace: As you can + see in [glibc]/sysdeps/mach/hurd/ptrace.c, ptrace on Hurd is simply a + wrapper around vm_read/write and more interfaces. + <tschwinge> hacklu: As the GDB port for Hurd is specific to Hurd by + definition, you can also directly use these calls in GDB for Hurd. + <tschwinge> ..., as it is currently done. + <hacklu> and in detail, the part 3 mach send a notification to the + excetption port is like this: gnu_wait get the message in mach_msg, and + then pass it to exc_serer by exc_server(),then exc_server call + S_exception_raise_request()? ? + <hacklu> tschwinge: yeah, I have see the ptrace.c. I was wonder about + nobody use ptrace in Hurd except TRACEME... + <tschwinge> hacklu: Right about »and in detail, [...]«. + <tschwinge> hacklu: It would be very good (and required for your + understanding anyway), if you could write up a list of things that + happens when a process (both under the control of GDB as well as without + GDB) is sent an exception (due to a breakpoint instruction, for example). + <tschwinge> Let me look something up. + <hacklu> tschwinge: what's the function of exc_server? if I can get the + notification in mach_msg(). + <youpi> to multiplex the message + <youpi> i.e. decoding it, etc. up to calling the S_ function with the + proper parameters + <youpi> exc_server being automatically generated, that saves a lot of code + <tschwinge> That is generated by MIG from the gdb/exc_request.defs file. + <tschwinge> You'll find the generated file in the GDB build directory. + <hacklu> I have wrote down the filenames. after this I will check that. + <tschwinge> hacklu: I suggest you also have a look at the Mach 3 Kernel + Principles book, + <http://www.gnu.org/software/hurd/microkernel/mach/documentation.html>. + <tschwinge> This also has some explanation of the thread/task's exception + mechanism. + <tschwinge> And of course, explains the RPC mechanism, which the exception + mechanism is built upon. + <tschwinge> And then, really make a step-by-step list of what happens; this + should help to better visualize what's going on. + <hacklu> ok. later I will update this list on my blog. + <tschwinge> hacklu: I cannot tell off-hand why GDB on Hurd is using + ptrace(PTRACE_TRACEME) instead of doing these calls manually. I will + have to look that up, too. + <hacklu> tschwinge: thanks. + <tschwinge> hacklu: Anyway -- you're asking sensible questions, so it seems + you're making progress/are on track. :-) + <hacklu> tschwinge: there is something harder than I had thought, I haven't + got any meaningful progress. sorry for this. + <tschwinge> hacklu: That is fine, and was expected. :-) (Also, you're + still busy with university.) + <hacklu> I will show more time and enthusiasm on this. + <tschwinge> hacklu: Oh, and one thing that may be confusing: as you may + have noticed, the names of the same RPC functions are sometimes slightly + different if different *.defs files. What is important is the subsystem + number, such as 2400 in [GDB]/gdb/exc_request.defs (and then incremented + per each routine/simpleroutine/skip directive). + <tschwinge> hacklu: Just for completeness, [hurd]/hurd/subsystems has a + list of RPC subsystems we're using. + <tschwinge> And the name given to routine 2400, for example, is just a + "friendly name" that is then used locally in the code where the *.defs + file has been processed by MIG. + <tschwinge> What a clumsy explanation of mine. But you'll get the idea, I + think. ;-) + <tschwinge> hacklu: And don't worry about your progress -- you're making a + lot of progress already (even if it doesn't look like it, because you're + not writing code), but the time spent on understanding these complex + issues (such as the RPC mechanism) definitely counts as progress, too. + <hacklu> tschwinge: not clearly to got it as I am not sensitive with the + MIG's grammer. But I know, the exc is the routine 2400's alias name? + <tschwinge> hacklu: I'd like to have you spend enough time to understand + these fundamental concepts now, and then switch to "hacking mode" (write + code) later, instead of now writing code but not understanding the + concepts behind it. + <hacklu> I have wrote a bit code to validate my understanding when I read + the soruce code. But the code not run. http://pastebin.com/r3wC5hUp + <tschwinge> The subsystem directive [...]. As well, let me just point you + to the documentation: + <http://www.gnu.org/software/hurd/microkernel/mach/mig/documentation.html>, + MIG - THE MACH INTERFACE GENERATOR, chapter 2.1 Subsystem identification. + <tschwinge> hacklu: Yes, writing such code for testing also is a good + approach. I will have to look at that in more detail, too. + * tschwinge guesses hacklu is probably laughing when seeing the years these + documents were written in (1989, etc.). ;-) + <hacklu> mach_msg make no sense in my code, and the process just hang. kill + -9 can't stop is either. + <braunr> hacklu: do you understand why kill -KILL might not work now ? + <hacklu> braunr: no, but I found I can use gdb to attach to that process, + then quit in gdb, the process quit too. + <hacklu> maybe that process was waiting a resume. + <braunr> something like that yes + <braunr> iirc it's related to a small design choice in the proc server + <braunr> something that put processes in an uninterruptible state when + being debugged + <hacklu> iirc ? + <braunr> if i recall cl=orrectly + <braunr> correctly* + <hacklu> like D status in linux? + <braunr> or T + <braunr> there has been a lot of improvements regarding signal handling in + linux over time so it's not really comparable now + <braunr> but that's the idea + <hacklu> in ps, i see the process STAT is THumx + <braunr> did you see that every process on the hurd has at least two + threads ? + <hacklu> no, but I have see that in hurd, the exception handler can't live + in the same context with the victim. so there must be at least two + threads. I think + <braunr> hacklu: yes + <braunr> that thread also handles regular signals + <braunr> in addition to mach exceptions + <braunr> (there are two levels of multiplexing in servers, first locating + the subsystem, then the server function) + <braunr> hacklu: if what i wrote is confusing, don't hesitate to ask for + clarifications (i really don't intend to make things confusing) + <hacklu> braunr: I don't know what you say about the "multiplexing in + servers". For instance, is it means how to pass message from mach_msg to + exc_server in gnu_wait()? + <braunr> hacklu: i said that the "message thread" handles both mach + exceptions and unix signals + <braunr> hacklu: these are two different interfaces (and in mach terms, + subsystems) + <braunr> hacklu: see hurd/msg.defs for the msg interface (which handles + unix signals) + <braunr> hacklu: to handle multiple interfaces in the same thread, servers + need to first find the right subsystem + <braunr> this is done by subsequently calling all demux functions until one + returns true + <braunr> (finding the right server function is done by these demux + functions) + <braunr> hacklu: see hurd/msgportdemux.c in glibc to see how it's done + there + <braunr> it's short actually, i'll past it here : + <braunr> return (_S_exc_server (inp, outp) || + <braunr> _S_msg_server (inp, outp)); + <braunr> hacklu: did that help ? + <hacklu> braunr: a bit more confusing. one "message thread" handles + exceptions and signals, means the message thread need to recive message + from two port. then pass the message to the right server which handle the + message. the server also should pick the right subsystem from a lot of + subsystems to handle the msg. is this ? + <braunr> the message thread is a server thread + <braunr> (which means every normal process is actually also a server, + receiving exceptions and signals) + <braunr> there may be only two ports, or more, it doesn't matter much, the + port set abstraction takes care of that + <hacklu> so the message thread directly pass the msg to the right + subsystem? + <braunr> not directly as you can see + <braunr> it tries them all until one is able to handle the incoming message + <braunr> i'm not sure it will help you with gdb, but it's important to + understand for a better general understanding of the system + <braunr> ugly sentence + <hacklu> ah, I see. like this in gnu-nat.c if(!notify_server(&msg.hdr, + &reply.hdr) && !exc_server(&msg.hdr...) + <braunr> yes + <hacklu> the thread just ask one by one. + <braunr> be careful about the wording + <braunr> the thread doesn't "send requests" + <braunr> it runs functions + <braunr> (one might be tempted to think there are other worker threads + waiting for a "main thread" to handle demultiplexing messages) + <hacklu> I got it. + <hacklu> the notify_server function is just run in the same context in + "message thread",and there is no RPC here. + <braunr> yes + <hacklu> and the notify_server code is generater by mig automatically. + <braunr> yes + + +# IRC, freenode, #hurd, 2013-06-29 + +[[!tag open_issue_documentation]] + + <hacklu> I just failed to build the demo on + this. http://walfield.org/pub/people/neal/papers/hurd-misc/ipc-hello.c + <hacklu> or, example in machsys.doc called simp_ipc.c + <pinotree> we don't use cthreads anymore, but pthreads + <hacklu> pinotree: em.. and I also failed to find the <servers/env_mgr.h> + in example of <A programmer's guide to MACH system call> + <pinotree> that i don't know + <hacklu> maybe the code in that book out-of-date + <teythoon> hacklu: mig and mach ipc documentation is quite dated + unfortunately, and so are many examples floating around the net + + <hacklu> btw, I have one more question. when I read <Mach 3 kernel + interface>. I find this state: When an exception occurs in a thread, the + thread sends an exception message to + <hacklu> its exception port, blocking in the kernel waiting for the receipt + of a reply. It is + <hacklu> assumed that some task is listening to this + <hacklu> port, using the exc_serverfunction to decode the messages and + then call the + <hacklu> linked in catch_exception_raise. It is the job of + catch_exception_raiseto handle the exception and decide the course of + action for thread. + <hacklu> that says, it assumed another task to recieve the msg send to one + thread's exception port. why another task? + <hacklu> I remmebered, there are at least two threads in one task, one is + handle the exception stuffs. + <braunr> there are various reasons + <braunr> first is, the thread causing the exception is usually not waiting + for a message + <braunr> next, it probably doesn't have all the info needed to resolve the + exception + <braunr> (depending on the system design) + <braunr> and yes, the second thread in every hurd process is the msg + thread, handling both mach exceptions and hurd signals + <hacklu> but in this state, I can't find any thing with the so called msg + thread + <braunr> ? + <hacklu> if exist a task to do the work, why we need this thread? + <braunr> this thread is the "task" + <hacklu> ? + <braunr> the msg thread is the thread handling exceptions for the other + threads in one task + <braunr> wording is important here + <braunr> a task is a collection of resources + <braunr> so i'm only talking about threads really + <braunr> 14:11 < hacklu> assumed that some task is listening to this + <braunr> this is wrong + <braunr> a task can't listen + <braunr> only a thread can + <hacklu> in you words, the two thread is in the same task? + <braunr> yes + <braunr> 14:32 < braunr> and yes, the second thread in every hurd process + is the msg thread, handling both mach exceptions and hurd signals + <braunr> process == task here + <hacklu> yeah, I always think the two thread stay in one task. but I found + that state in <mach 3 kernel interface>. so I confuzed + <hacklu> s/confuzed/confused + <braunr> statement you mean + <hacklu> if two thread stay in the same task. and the main thread throw a + exception, the other thread to handle it? + <braunr> depends on how it's configured + <braunr> the thread receiving the exceptions might not be in the same task + at all + <braunr> on the hurd, only the second thread of a task receives exception + <braunr> s + <hacklu> I just wonder how can the second thread catch the exception from + its containning task + <braunr> forget about tasks + <braunr> tasks are resource containers + <braunr> they don't generate or catch exceptions + <braunr> only threads do + <braunr> for each thread, there is an exception port + <braunr> that is, one receive right, and potentially many send rights + <braunr> the kernel uses a send right to send exceptions + <braunr> the msg thread waits for messages on the receive right + <braunr> that's all + <hacklu> ok. if I divide zero in main thread, the kernel will send a msg to + the main thread's exception port. and then, the second thread(in the same + task) is waiting on that port. so he get the msg. is it right? + <braunr> don't focus on main versus msg thread + <braunr> it applies to all other threads + <braunr> as well + <braunr> otherwise, you're right + <hacklu> ok, just s/main/first + <braunr> no + <braunr> main *and* all others except msg + <hacklu> main *and* all others except msg ? + <braunr> the msg thread gets exception messages for all other threads in + its task + <braunr> (at least, that's how the hurd configures things) + <hacklu> got it. + <hacklu> if the msg thread throw exception either, who server for himself? + <braunr> i'm not sure but i guess it's simply forbidden + <hacklu> i used gdb to attach a little progrom which just contains a divide + zero. and I only found the msg thread is in the glibc. + <braunr> yes + <hacklu> where is the msg thread located in. + <braunr> it's created by glibc + <hacklu> is it glibc/hurd/catch-exc.c? + <braunr> that's the exception handling code, yes + <hacklu> there are some differences between the code and the state in <mach + 3 system interface>. + <braunr> state or statement ? + <hacklu> staement + <braunr> which one ? + <hacklu> http://pastebin.com/ZTBrUAsV + When an exception occurs in a thread, the thread sends an exception + message to + its exception port, blocking in the kernel waiting for the receipt of a + reply. It is + assumed that some task is listening (most likely with mach_msg_server) + to this + port, using the exc_serverfunction to decode the messages and then + call the + linked in catch_exception_raise. It is the job of + catch_exception_raiseto handle the exception and decide the course of + action for thread. The state of the + blocked thread can be examined with thread_get_state. + <braunr> what difference ? + <hacklu> in the code, I can't find things like exc_server,mach_msg_server + <braunr> uh + <braunr> ok it's a little tangled + <braunr> but not that much + <braunr> you found the exception handling code, and now you're looking for + what calls it + <braunr> simple + <braunr> see _hurdsig_fault_init + <hacklu> from that statemnet I thought there are another _task_ do the + exception things for all of the systems thread before you have told me + the task means the msg thread. + <braunr> again + <braunr> 14:47 < braunr> forget about tasks + <braunr> 14:47 < braunr> tasks are resource containers + <braunr> 14:47 < braunr> they don't generate or catch exceptions + <braunr> 14:47 < braunr> only threads do + <hacklu> yeah, I think that document need update. + <braunr> no + <braunr> it's a common misnomer + <braunr> once you're used to mach concepts, the statement is obvious + <hacklu> braunr: so I need read more :) + <hacklu> _hurdsig_fault_init send exceptions for the signal thread to the + proc server? + <hacklu> why come about _proc_ server? + <braunr> no it gives the proc server a send right for signals + <braunr> exceptions are a mach thing, signals are a hurd thing + <braunr> the important part is + <braunr> err = __thread_set_special_port (_hurd_msgport_thread, + <braunr> THREAD_EXCEPTION_PORT, sigexc); + <hacklu> this one set the exception port? + <braunr> yes + <braunr> hm wait + <braunr> actually no, wrong part :) + <braunr> this sets the excpetion port for the msg thread (which i will call + the signal thread as mentioned in glibc) + <hacklu> but the comment above this line, Direct signal thread exceptions + to the proc server means what? + <braunr> that the proc server handles exceptions on the signal thread + <hacklu> the term signal thread equals the term msg thread? + <braunr> yes + <hacklu> so, the proc server handles the exceptions throwed by the msg + thread? + <braunr> looks that way + <hacklu> feels a little strange. + <braunr> why ? + <braunr> this thread isn't supposed to cause exceptions + <braunr> if it does, something is deeply wrong, and something must clean + that task up + <braunr> and the proc server seems to be the most appropriate place from + where to do it + <hacklu> why need a special server to just work the msg thread? I don't + think that thread will throw exception frequentlly + <braunr> what does frequency have to do with anything here ? + <braunr> ok the appropriate code is _hurdsig_init + <braunr> the port for receiving exceptions is _hurd_msgport + <braunr> the body of the signal thread is _hurd_msgport_receive + <hacklu> aha, in the _hurd_msgport_receive I have finally found the + while(1) loop mach_msg_server(). + <hacklu> so the code is conform with the documents. + <hacklu> braunr: [21:18] <braunr> what does frequency have to do with + anything here ? yes, I have totally understood your words now. thank you + very much. + <braunr> :) + + +# IRC, freenode, #hurd, 2013-07-01 + + <hacklu> hi. this is my weekly + report. http://hacklu.com/blog/gsoc-weekly-report2-124/ welcome to any + comment + <hacklu> teythoon: I only get clear about the rpc stuff. seems a lot behind + my plan + <youpi> good progress :) + <hacklu> I have wrote the details of the exception handle which was asked + by tschwing_ last week. Am I all right in my post? + <youpi> hacklu: as far as I understand signals, yes :) + <hacklu> youpi: thanks for god, I am on the right way finally... :) + <hacklu> the mig book says simpleroutine is the one use to implement asyn + RPCs which doesn't expect an reply. But I have found a place to pass an + reply port to the RPC interface which has been declared as simpleroutine + <youpi> hacklu: probably the simpleroutine hardcodes a reply port? + + <youpi> hacklu: about _hurd_internal_post_signal, this is the hairiest part + of GNU/Hurd, signal handling + <youpi> simply because it's the hairiest part of POSIX :) + <youpi> you probably want to just understand that it implements the + POSIXity of signal delivering + <youpi> i.e. deliver/kill/suspend the process as appropriate + <youpi> I don't think you'll need to dive more + <hacklu> aha. + <hacklu> it will save a lot of time. + <hacklu> it seems like the wait_for_inferior() in gdb. which also has too + many lines and too many goto + <youpi> hacklu: btw, which simpleroutine were you talking about ? + <hacklu> I forget where it is, I am finding it now. + <youpi> which version of gdb are you looking the source of? + <youpi> (in mine, wait_for_inferior is only 45 lines long) + <hacklu> I dont know how to pick the verison, I just use the git + version. maybe I give a wrong name. + <youpi> ok + <hacklu> youpi:I remembered, my experience comes from here + http://www.aosabook.org/en/gdb.html. (All of this activity is managed by + wait_for_inferior. Originally this was a simple loop, waiting for the + target to stop and then deciding what to do about it, but as ports to + various systems needed special handling, it grew to a thousand lines, + with goto statements criss-crossing it for poorly understood + <hacklu> reasons.) + <hacklu> youpi: the simpleroutine is gdb/gdb/exc_request.defs + <youpi> so there is indeed an explicit reply port + <hacklu> but simpleroutine is for no-reply use. why use reply port here? + <youpi> AIUI, it's simply a way to make the request asynchronous, but still + permit an answer + <hacklu> ok, I will read the mig book carefully. + <braunr> hacklu: as youpi says + <braunr> a routine can be broken into two simpleroutines + <braunr> that's why some interfaces have interface.defs, + interface_request.defs and interface_reply.defs files + <braunr> nlightnfotis: in mach terminology, a right *is* a capability + <braunr> the only thing mach doesn't easily provide is a way to revoke them + individually + <nlightnfotis> braunr: Right. And ports are associated with the process + server and the kernel right? I mean, from what I have understood, if a + process wants to send a signal to another one, it has to do so via the + ports to that process held by the process server + <nlightnfotis> and it has to establish its identity before doing so, so + that it can be checked if it has the right to send to that port. + <braunr> yes + <nlightnfotis> do process own any ports? or are all their ports associated + with the process server? + <nlightnfotis> *processes + <braunr> mach ports were intended for a lot of different uses + <braunr> but in the hurd, they mostly act as object references + <braunr> the process owning the receive right (one at most per port) + implements the object + <braunr> processes owning send rights invoke methods on the object + <braunr> use portinfo to find out about the rights in a task + <braunr> (process is the unix terminology, task is the mach terminologyà + <braunr> ) + <braunr> i use them almost interchangeably + <nlightnfotis> ahh yes, I remember about the last bit. And mach tasks have + a 1 to 1 association with user level processes (the ones associated with + the process server) + <braunr> the proc server is a bit special because it has to know about all + processes + <braunr> yes + +In context of [[open_issues/libpthread/t/fix_have_kernel_resources]]: + + <braunr> hacklu: if you ever find out about either glibc or the proc server + creating one receive right for each thread, please let me know + + +# IRC, freenode, #hurd, 2013-07-07 + + <hacklu> how fork() goes? + <pinotree> see sysdeps/mach/hurd/fork.c in glibc' sources + <hacklu> when the father has two thread( main thread and the signal thead), + if the father call fork, then the child inmediatelly call exev() to + change the excute file. how many thread in the children? + <hacklu> For instance, the new execute file also have two thread. + <hacklu> will the exev() destroyed two threads and then create two new? + <hacklu> s/exev()/excv() + <hacklu> s/exev()/exec() :) + + <hacklu> what libhurduser-2.13.so does? + <hacklu> where can I find this source? + <pinotree> contains all the client stubs for hurd-specific RPCs + <pinotree> it is generated and built automatically within the glibc build + process + + <hacklu> and what is the "proc" server? + <pinotree> what handles in user spaces the processes + <hacklu> so if I call proc_wait_request(), I will go into the + S_proc_wait_reply? + <hacklu> thanks, I have found that. + + +# IRC, freenode, #hurd, 2013-07-08 + + <hacklu> hi, this is my weekly + report. http://hacklu.com/blog/gsoc-weekly-report3-137/ + <hacklu> this week I have met a lot of obstacles. And I am quite desired to + participate in this meeting. + <tschwinge> hacklu: So from your report, the short version is: you've been + able to figure out how the things work that you were looking at (good!), + and now there are some new open questions that you're working on now. + <tschwinge> hacklu: That sounds good. We can of course try to help with + your open questions, if you're stuck figuring them out on your own. + <hacklu> tschwinge: the most question is: what is the proc server? why need + to call proc_get_reqeust() before the mach_msg()? + <hacklu> and Is there exist any specific running sequence between father + and child task after fork()? And I found the inferior always call the + trace_me() in the same time(the trace me printf always in the same line + of the output log). which I have post in my report. + <tschwinge> hacklu: The fork man-page can provide a high-level answer to + your Q3: »The child process is created with a single thread—the one that + called fork(). The entire virtual address space of the parent is + replicated in the child, including the states of mutexes, condition + variables, and other pthreads objects [...]« + <tschwinge> hacklu: What happens in GNU Hurd is that the signal thread is + also "cloned" (additionally to the thread which called fork), but then it + (the signal thread) is re-started from the beginning. (So this is very + much equivalent to creating a new signal thread.) + <tschwinge> hacklu: Then, upon exec, a new memory image is created/loaded, + replacing the previous one. [glibc]/sysdeps/mach/hurd/execve.c. What + actually happens with the existing thread (in particular, the signal + thread) I don't know off-hand. Then answer is probably found in + [glibc]/hurd/hurdexec.c -- and perhaps some code of the exec server + ([hurd]/exec/). + <hacklu> I have checked the status of my regiter mail to FSF. it says it + had arrived in USA. + <tschwinge> hacklu: OK, good. + <tschwinge> hacklu: This is some basic information about the observer_* + functions is GDB: + http://sourceware.org/gdb/current/onlinedocs/gdbint/Algorithms.html#index-notifications-about-changes-in-internals-57 + »3.10 Observing changes in gdb internals«. + <hacklu> tschwinge: not too clear. I will think this latter. and what is + the proc server? + <teythoon> hacklu: /hurd/proc, maps unix processes to mach threads afaiui + <hacklu> teythoon: question is, the mach_msg() will never return unless I + called proc_wait_request() first. + <teythoon> hacklu: sorry, I've no idea ;) + <hacklu> teythoon: :) + <tschwinge> hacklu: I will have to look into that myself, too; don't know + the answer off-hand. + <tschwinge> hacklu: In your blog you write proc_get_request -- but such a + functions doesn't seems to exist? + <hacklu> tschwinge: s/proc_get_request/proc_wait_request called in + gun_wait() [gnu-nat.c] + <tschwinge> hacklu: Perhaps the wait man-page's description of WUNTRACED + gives a clue: »also return if a child has stopped [...]«. But it also to + me is not yet clear, how this relates to the mach_mag call, and how the + proc server exactly is involved in it. + <tschwinge> I'm reading various source code files. + <tschwinge> At least, I don't undestand why it is required for an exception + to be forwarded. + <hacklu> if I need to read the proc server source code? + <tschwinge> I can see how it to become relevant for the case that GDB has + to be informed that the debugee has exited normally. + <tschwinge> hacklu: Yeah, probably you should spend some time with that, as + it will likely help to get a clearer picture of the situation, and is + relevant for other interactions in GDB, too. + <tschwinge> hacklu: By the way, if you find that pieces of the GDB source + code (especially the Hurd files of it) are insufficiently documented, + it's a very good idea, once you have figured out something, to add more + source code comments to the existing code. Or writed these down + separately, if that is easier. + <hacklu> which is the proc server? hurd/exec ? + <hacklu> that ok, I already comment things on my notes. + <tschwinge> hacklu: [Hurd]/proc/ + <tschwinge> hacklu: And [Hurd]/hurd/process*.defs + <hacklu> got it + <tschwinge> hacklu: I'll have to experiment a bit with your HDebugger + example, but I'm out of time right now, sorry. Will continue later. + <hacklu> tschwinge: yep, the HDebugger has a problem, if you put the + sleep() after the printf in the just_print(), thing will hang. + <hacklu> tschwinge: and I am a little curious about how do you find my + code? I dont't remember I have mentioned that :) + <hacklu> tschwinge: I have post my gihub link in the last week report, I + found that. + <tschwinge> hacklu: That's how I found it, yes. + <hacklu> tschwinge: :) + + +# IRC, freenode, #hurd, 2013-07-14 + + <hacklu> hi. what is a process's msgport? + <hacklu> And where can I find the msg_sig_post_untraced_request()? + <hacklu> (msg_sig_post* in [hurd]/hurd/msg_defs) + <hacklu> this is my debugger demo code + https://github.com/hacklu/HDebugger.git use make test to run the demo. I + put a breakpoint before the second printf in hello_world(inferior + program). but I can't resume execution from that. + <hacklu> could somebody give me some suggestions? thanks so much. + <teythoon> hacklu: % make test + <teythoon> make: *** No rule to make target `exc_request_S.c', needed by + `all'. Stop. + <hacklu_> teythoon: updated, forget to git add that file . + <teythoon> hacklu_: cool, seems to work now + <teythoon> will look into this tomorrow :) + <hacklu_> exit + <hacklu_> teythoon: not work. the code can,t resume from a breakpoint + + +# IRC, freenode, #hurd, 2013-07-15 + + <hacklu> hi, this is my weekly + report. http://hacklu.com/blog/gsoc-weekly-report4-148/ + <hacklu> sadly to unsolve the question of resume from breakpoint. + <teythoon> hacklu: have you tried to figure out what gdb does to resume a + process? + <hacklu> teythoon: hi. em, I have tried, but haven't find the magic in gdb + yet. + <teythoon> have you tried rpctrace'ing gdb? + <hacklu> no, rpctrace has too many noise. I turned on the debug in gdb. + <hacklu> I don't want rpctrace start gdb as its child task. if it can + attach at some point instead of at start + <teythoon> hacklu: you don't need to use gdb interactively, you could pipe + some commands to it + <hacklu> teythoon: that sounds a possible way. I am try it, thank you + <hacklu> youpi: gdb can't work correctlly with rpctrace even in batch + mode. + <hacklu> get something like this "rpctrace: get an unknown send right from + process 2151" + <youpi> hacklu: well, ideally, fix rpctrace ); + <youpi> ;) + <youpi> hacklu: but you can also as on the list, perhaps somebody knows + what you need + <hacklu> ok. + <hacklu> or I should debug gdb more deeply. + <youpi> do both + <youpi> so either of them may win first + + <hacklu> braunr: I have found that, if there is no exception appears, the + signal thread will not be createed. Then there is only one thread in the + task. + + +# IRC, freenode, #hurd, 2013-07-17 + + <hacklu__> braunr: ping + <braunr> hacklu__: yes ? + <hacklu__> I have reply your email + <braunr> i don't understand + <braunr> "I used this (&_info)->suspend_count to get the sc value." + <braunr> before the thread_info call ? + <hacklu__> no, after the call + <braunr> but you have a null pointer + <braunr> the info should be returned in info, not _info + <hacklu__> strange thing is the info is a null pointer. but _info not + <braunr> _info isn't a pointer, that's why + <braunr> the kernel will use it if the data fits, which is usually the case + <hacklu__> in the begin , the info=&_info. + <braunr> and it will dynamically allocate memory if it doesn't + <braunr> yes + <braunr> info should still have that value after the call + <hacklu__> but the call had change it. this is what I can;t understand. + <braunr> are you completely sure err is 0 on return ? + <hacklu__> since the parameter is a pointer to pointer, the thread_info can + change it , but I don't think it is a good ideal to set it to null + pointer without any err . + <hacklu__> yes. i am sure + <braunr> info_len is wrong + <braunr> it should be the number of integers in _info + <braunr> i.e. sizeof(_info) / sizeof(unsigned int) + <braunr> i don't think that's the problem though + <braunr> yes, THREAD_BASIC_INFO_COUNT is already exactly that + <braunr> hm not exactly + <braunr> yes, exactly in fact + <hacklu__> I try to set it by hand, not use the macro. + <braunr> the macro is already defined as #define THREAD_BASIC_INFO_COUNT + (sizeof(thread_basic_info_data_t) / sizeof(natural_t)) + <hacklu__> the info_len is 13. I checked. + <braunr> so, i said something wrong + <braunr> the call doesn't reallocate thread_info + <braunr> it uses the provided storage, nothing else + <braunr> yes, your call is wrong + <braunr> use thread_info (thread->port, THREAD_BASIC_INFO, (int *) info, + &info_len); + <hacklu__> em. thread_info (thread->port, THREAD_BASIC_INFO, (int *) &info, + &info_len); + <braunr> &info would make the kernel erase the memory where info (the + pointer) was stored + <braunr> info, not &info + <braunr> or &_info directly + <braunr> i don't see the need for an intermediate pointer here + <braunr> ideally, avoid the cast + <hacklu__> but in gnu-nat.c line 3338, it use &info. + <braunr> use a union with both thread_info_data_t and + thread_basic_info_data_t + <braunr> well, try it my way + <braunr> i think they're wrong + <hacklu__> ok, you are right, use info it is ok. the value is the same as + &_info after the call. + <hacklu__> but the suspend_count is zero again. + <braunr> check the rest of the result to see if it's consistent + <hacklu__> I think this line need a patch. + <hacklu__> what you mean the rest of the result? + <braunr> the thread info + <braunr> run_state, sleep_time, creation_time + <braunr> see if they make sense + <hacklu__> ok, I try to dump it + <braunr> bbl + <hacklu__> braunr: thread [118] suspend_count=0 + <hacklu__> run_state=3, flags=1, sleep_time=0, + creation_time.second=1374079641 + <hacklu__> something like this, seems no problems. + + +# IRC, freenode, #hurd, 2013-07-18 + + <hacklu__> how to get the thread state from TH_STATE_WAITING to + TH_STATE_RUNNING + <braunr> hacklu__: + http://www.gnu.org/software/hurd/gnumach-doc/Thread-Execution.html#Thread-Execution + <braunr> hacklu__: ah waiting + <braunr> hacklu__: this means the thread is waiting for an event + <braunr> so probably waiting for a message + <braunr> or an internal kernel event + <hacklu__> braunr: so I need to send it a message. I think I maybe forget + to send some reply message. + <braunr> hacklu__: i'm really not sure about those low level details + <braunr> confirm before doing anything + <hacklu__> the gdb has called msg_sig_post_untraced_request(), I don't get + clear about this function, I just call it as the same, maybe I am wrong . + <hacklu__> how will if I send a CONT to the stopped process? maybe I should + try this. + <hacklu__> when the inferior is in waiting + status(TH_STATE_WAITING,suspend_count=0), I use kill to send a CONT. then + the become(TH_STATE_STOP,suspend_count=1). when I think I am near the + success,I call thread_resume(),inferior turn out to be (TH_STATE_WAITING, + suspend_count=0). + <braunr> so yes, probably waiting for a message + <hacklu__> braunr: after send a CONT to the inferior, then send a -9 to the + debugger, the inferior continue!!! + <braunr> probably because it was notified there wasn't any sender any more + <hacklu__> that's funny, I will look deep into thread_resume and kill + <braunr> (gdb being the sender here) + <hacklu__> in hurd, when gdb attach a inferior, send signal to the + inferior, who will get the signal first? the gdb or the inferior? + <hacklu__> quite differnet with linux. seems the inferior get first + <braunr> do you mean gdb catches its own signal through ptrace on linux ? + <hacklu__> kkk + <braunr> ? + + +# IRC, freenode, #hurd, 2013-07-20 + + <hacklu> braunr: yeah, on Linux the gdb catch the signal from inferior + before the signal handler. And that day my network was broken, I can't + say goodbye to you. sorry for that. + + +# IRC, freenode, #hurd, 2013-07-22 + + <hacklu> hi all, this is my weekly + report. http://hacklu.com/blog/gsoc-weekly-report5-152/ + <teythoon> good to hear that you got the resume issue figured out + <hacklu> teythoon: thanks :) + <teythoon> hacklu: so your next step is to port gdbserver to hurd? + <hacklu> yep, I am already begin to. + <hacklu> before the mid-evaluate, I must submit something. I am far behind + my personal expections + <tschwinge> hacklu: You've made great progress! Sorry, for not being able + to help you very much: currently very busy with work. :-| + <tschwinge> hacklu: Working on gdbserver now is fine. I understand you + have been working on HDebugger to get an understanding of how everyting + works, outside of the huge GDB codebase. It's of course fine to continue + working on HDebugger to test things, etc., and that also counts very much + for the mid-term evaluation, so nothing to worry about. :-) + <hacklu> but I have far away behind my application on GSOC. I haven't + submit any patches. is it ok? + <tschwinge> hacklu: Don't worry. Before doing the actual work, things + always look much simpler than they will be. So I was expecting/planning + for that. + <tschwinge> The Hurd system is complex, with non-trivial and sometimes + asynchronous communication between the different components, and so it + takes some time to get an understanding of all that. + <hacklu> yes, I haven't get all clear about the signal post. that's too + mazy. + <tschwinge> hacklu: It surely is, yes. + <hacklu> tschwinge: may you help me to understand the msg_sig_post(). I + don't want to understand all details now, but I want to get the _right_ + understanding of the gerneral. + <hacklu> as I have mentioned on my weekly report, gdb is listening on the + inferior's exception port, then gdb post a signal to that port. That + says: gdb post a message to herself, and handle it. is this right? + <hacklu> tschwinge: [gdb]/gdb/gnu-nat.c (line 1371), and + [glibc]/hurd/hurdsig.c(line 1390) + <tschwinge> hacklu: My current understanding is that this is a "real" + signal that is sent to the debugged process' signal thread (msgport), and + when that process is resumed, it will process that signal. + <tschwinge> hacklu: This is different from the Mach kernel sending an + exception signal to a thread's exception port, which GDB is listening to. + <tschwinge> Or am I confused? + <hacklu> is the msgport equal the exception port? + <hacklu> in my experience, when the thread haven't cause a exception, the + signal thread will not be created. after the exception occured, the + signal thread is come out. so somebody create it, who dose? the mach + kernel? + <tschwinge> hacklu: My understanding is that the signal thread would always + be present, because it is set up early in a process' startup. + <hacklu> but when I call task_threads() before the exception appears, only + on thread returned. + <tschwinge> "Interesting" -- another thing to look into. + <tschwinge> hacklu: Well, you must be right: GDB must also be listening to + the debugged process' msgport, because otherwise it wouldn't be able to + catch any signals the process receives. Gah, this is all too complex. + <hacklu> tschwinge: that's maybe not. gdb listening on the task's exception + port, and the signal maybe handle by the signal thread if it could + handle. otherwise the signal thread pass the exception to the task's + exception port where gdb catched. + <tschwinge> hacklu: Ah, I think I now get it. But let me first verify... + ;-) + + <hacklu> something strange. I have write a program to check whether create + signal threads at begining, the all created! + <hacklu> tschwinge: this is my test code and + result. http://pastebin.com/xtM6DUnG + cat test.c + #define _GNU_SOURCE 1 + #include <stdlib.h> + #include <stdio.h> + #include <errno.h> + #include <mach.h> + #include <mach_error.h> + int main(int argc,char** argv) + { + mach_port_t task_port; + thread_array_t threads[5]; + mach_msg_type_number_t num_threads[5]; + error_t err; + task_port = mach_task_self(); + int i; + int j; + for(i=0;i<5;i++) + if(task_port){ + err = task_threads(task_port,&threads[i],&num_threads[i]); + if(err) + printf("err\n"); + } + for(i=0;i<5;i++){ + printf("===============\n"); + printf("has %d threads now\n",num_threads[i]); + for(j=0;j<num_threads[i];j++) + printf("thread[%d]=%d\n",j,threads[i][j]); + } + return 0; + } + + + and the output + ./a.out + =============== + has 2 threads now + thread[0]=87 + thread[1]=97 + =============== + has 2 threads now + thread[0]=87 + thread[1]=97 + =============== + has 2 threads now + thread[0]=87 + thread[1]=97 + =============== + has 2 threads now + thread[0]=87 + thread[1]=97 + =============== + has 2 threads now + thread[0]=87 + thread[1]=97 + <hacklu> tschwinge: the result is different with HDebugger case. + + <tschwinge> hacklu: It is my understanding that the two sig_post_untraced + RPC calls in inf_signal indeed are invoked on the real msgport (signal + thread) if the debugged process. + <tschwinge> That port is retrieved via the + INF_MSGPORT_RPC/INF_RESUME_MSGPORT_RPC macro, which invoked + proc_getmsgport on the proc server, and that will return (unless + overridden by proc_setmsgport, but that isn't done in GDB) the msgport as + set by [glibc]/hurd/hurdinit.c:_hurd_new_proc_init or _hurd_setproc. + <tschwinge> inf_signal is called from gnu_resume, which is via + [target_ops]->to_resume is called from target.c:target_resume, which is + called several places, for example infrun.c:resume which is used to a) + just resume the debugged process, or b) resume it and have it handle a + Unix signal (such as SIGALRM, or so), when using the GDB command »signal + SIGALRM«, for example. + <tschwinge> So such a signal would then not be intercepted by GDB itself. + <tschwinge> By the way, this is all just from reading the code -- I hope I + got it all right. + + <tschwinge> Another thing: In Mach 3 Kernel Principles, the standard + sequence described on pages 22, 23 is thread_suspend, thread_abort, + thread_set_state, thread_resume, so you should probably do that in + HDebugger too, and not call thread_set_state before. + <tschwinge> I would hope the GDB code also follows the standard sequence? + Can you please check that? + + <tschwinge> The one thing I'm now confused about is where/how GDB + intercepts the standard setup (probably in glibc's signaling mess?) so + that it receives any signals raised in the debugged process. + <tschwinge> But I'll have to continue later. + + <hacklu___> tschwinge: thanks for your detail answers. I don't realize that + the gnu_resume will resume for handle a signal, much thanks for point + this:) + <hacklu___> tschwinge: I am not exactly comply with <Mach 3 kernel + principles> when I call thread_set_state. but I have called a + task_suspend before. I think it's not too bad:) + <tschwinge> hacklu___: Yes, but be aware that gnu_resume is only relevant + if a signal is to be forwarded to the debugged process (to be handled + there), but not for the case where GDB intercepts the signal (such as + SIGSEGV), and handles it itself without then forwarding it to the + application. See the »info signals« GDB command. + <hacklu___> I also confused about when to start the signal thread. I will + do more experiment. + <hacklu___> I have found this: when the inferior is stop at a breakpoint, I + use kill to send a CONT to it, the HDebugger will get this message who + listening on the exception port. + + +# IRC, freenode, #hurd, 2013-07-28 + + <hacklu_> how to understand the rpctrace output? + <hacklu_> like this. 142<--143(pid15921)->proc_mark_stop_request (19 0) + 125<--1 + <hacklu_> 27(pid-1)->msg_sig_post_request (20 5 task108(pid15919)); + <hacklu_> what is the (pid-1)? the kernel? + <teythoon> 1 is /hurd/init + <hacklu_> pid-1 not means minus 1? + <teythoon> ah, funny, you're right... I dunno then + <teythoon> 2 is the kernel though + <hacklu_> the 142<--143 is port name? + <teythoon> could very well be, but I'm not sure, sorry + <hacklu_> the number must be the port name. + <teythoon> anyone knows why /hurd/init does not get dead name notifications + for /hurd/exec like it does for any other essential server? + <teythoon> as far as I can see it successfully asks for them + <teythoon> about rpctrace, it poses as the kernel for its children, parses + and relays any messages sent over the childrens message port, right? + + +# IRC, freenode, #hurd, 2013-07-29 + + <hacklu_> hi. this is my weekly + report. http://hacklu.com/blog/gsoc-weekly-report6-156/ + <teythoon> hacklu_: the inferior voluntarily stops itself if it gets a + signal and notifies its tracer? + <hacklu_> yes + <teythoon> what if it chose not to do so? undebugable program? + <hacklu_> debugged program will be set an flag so called + hurdsig_traced. normal program will handle the signal by himself. + <hacklu_> in my env, I found that when GDB attach a running program, gdb + will not catch the signal send to the program. May help me try it? + <teythoon> it doesn't? I'll check... + <teythoon> hacklu_: yes, you're right + <hacklu_> you can just gdb a loop program, and kill -CONT to it. If I do + this I will get "Can't wait for pid 12332:NO child processes" warning. + <teythoon> yes, I noticed that too + <teythoon> does gdb reparent the tracee? + <hacklu_> I don't think this is a good behavior. gdb should get inferior's + signal + <teythoon> absolutely + <hacklu_> In linux it does, not sure about hurd. but I think it should. + <teythoon> definitively. there is proc_child in process.defs, but that may + only be used once to set the parent of a process + <hacklu_> gdb doesn't set the inferior as its child process if attached a + running procss in HURD. + + <tschwinge> hacklu_: So you figured out this tracing/signal stuff. Great! + <hacklu_> tschwinge: Hi. not exactly. + <hacklu_> as I have mentioned, gdb can't get signal when attach to a + running process. + <hacklu_> I also want to know how to build glibc in hurd. I have got this " + relocation error: ./libc.so: symbol _dl_find_dso_for_object, version + GLIBC_PRIVATE not defined in file ld.so.1 with link time reference" when + use LD_PRELOAD=./my_build_glibc/libc.so + <tschwinge> hacklu: You can't just preload the new libc.so, but you'll also + need to use the new ld.so. Have a look at [glibc-build]/testrun.sh for + how to invoke these properly. Or, link with + »-Wl,-dynamic-linker=[glibc-build]/elf/ld.so,-rpath,[glibc-build]:[glibc-build]/elf + -L [glibc-build] -L [glibc-build]/elf«. If using the latter, I suggest + to also add »-Wl,-t« to verify that you're linking against the correct + libraries, and »ldd + <tschwinge> [executable]« to verify that [€xecutable] will load the correct + libraries when invoked. + <hacklu> I will try that, and I can't find this call + pthread_cond_broadcast(). which will called in the proc_mark_stop + <tschwinge> hacklu: Oh, right, you'll also need to add libpthread (I think + that's the directory name?) to the rpath and -L commands. + <hacklu> is libpthread a part of glibc or hurd? + <pinotree> glibc + <NlightNFotis> hacklu: it is a different repository available here + http://git.savannah.gnu.org/cgit/hurd/libpthread.git/ + <hacklu> tschwinge: thanks for that, but I don't think I need help about + the comiler error now, it just say missing some C file. I will look into + the Makefile to verify. + <NlightNFotis> but I think it's a part of glibc as a whole + <tschwinge> hacklu: OK. + <tschwinge> glibc is/was a stand-alone package and library, but in Debian + GNU/Hurd is nowadays integrated into glibc's build process. + <hacklu> NlightNFotis: thanks. I only add hurd, glibc, gdb,mach code to my + cscope file. seems need to add libpthread. + <tschwinge> hacklu: If you use the Debian glibc package, our libpthread + will be in the libpthread subdirectory. + <tschwinge> Ignore nptl, which is used for the Linux kernel. + <hacklu> tschwinge:BTW, I have found that, to continue the inferior from a + breakpoint, doesn't need to call msg_sig_post_untraced. just call + thread_abort and thread_resume is already ok. + <hacklu> I get the glibc from http://git.savannah.gnu.org/cgit/hurd. + <tschwinge> hacklu: That sounds about right, because you want the inferior + to continue normally, instead of explicitly sending a (Unix) signal to + it. + <tschwinge> hacklu: I suggest you use: »apt-get source eglibc« on your Hurd + system. + <tschwinge> hacklu: The Savannah repository does not yet have libpthread + integrated. I have this on my TODO list... + <hacklu> tschwinge: no, apt-get source doesn't work in my Hurd. I got any + code from git clone *** + <pinotree> you most probably lack the deb-src entry in your sources.list + <tschwinge> hacklu: Do you have deb-src lines in /etc/apt/source-list? Or + how does it fail? + <hacklu> tschwinge: I have deb-src lines. and apt-get complain that: E: + Unable to find a source package for eglibc or E: Unable to find a source + package for glibc + <youpi> hacklu: which deb-src lines do you have? + <hacklu> and piece of my source_list : deb + http://ftp.debian-ports.org/debian unreleased main deb-src + http://ftp.debian-ports.org/debian unreleased main + <youpi> you also need a deb-src line with the main archive + <youpi> deb-src http://cdn.debian.net/debian unstable main + <tschwinge> hacklu: Oh, hmm. And you did run »apt-get update« before? + That aside, there also is <http://snapshot.debian.org/package/eglibc/> + that you can use. You'll need the *.dsc and *.debian.tar.xz files + corresponbding to your version of glibc, and the *.orig.tar.xz file. And + then run »dpkg-source -x *.dsc«. + <tschwinge> The Debian snapshot is often very helpful if you need source + packages that are no longer in the main Debian repository. + <youpi> or simply running dget on the dsc url + <tschwinge> Oh. Good to know. + <youpi> e.g. dget + http://cdn.debian.net/debian/pool/main/e/eglibc/eglibc_2.17-7.dsc + <hacklu> the network is slowly. and I am in apt-get update. + <youpi> I will be away from this evening until sunday, too + <hacklu> what the main difference between the source site? + <hacklu> is dget means wget? + <pinotree> no + <hacklu> not exist in linux? + <pinotree> it does, in devscripts + <pinotree> it's a debian tool + <hacklu> oh, yes, I have installed devscripts. + <hacklu> I have got the libphread code, thanks. + + <braunr> teythoon: the simple fact that this msg thread exists to receive + requests and that these requests are sent by ps and procfs is a potential + DoS + <teythoon> braunr: but does that mean that on Hurd a process can prevent a + debugger from intercepting signals? + <braunr> teythoon: yes + <braunr> that's not a problem for interactive programs + <braunr> it's part of the hurd design that programs have limited trust in + each other + <braunr> a user can interrupt his debugger if he sees no activity + <braunr> that's more of a problem for non interactive system stuff like + init scripts + <braunr> or procfs + <hacklu> why gdb can't get inferior's signal if attach a running process? + <braunr> hacklu: try to guess + <hacklu> braunr: it is not a reasonable thing. I always think it should + catch the signal. + <braunr> hacklu: signals are a unix thing built on top of mach + <braunr> hacklu: think in terms of ports + <braunr> all communication on the hurd goes through ports + <hacklu> but when use gdb to start a process and debugg it, this way, gdb + can catch the signal + <braunr> hacklu: my guess is : + <braunr> when starting a process, gdb can act as a proxy, much like + rpctrace + <braunr> when attaching, it can't + <hacklu> braunr: ah, my question should ask like this: why gdb can't set + the inferior as its child process when attaching it? or it can not ? + <braunr> hacklu: i'm not sure, the proc server is one of the parts i know + the less + <braunr> but again, i guess there is no facility to update the msg port of + a process in the proc server + <braunr> check that before taking it as granted + <hacklu> braunr: aha, I alway think you know everything:) + <tschwinge> braunr: There is: setmsgport or similar. + <braunr> if there is one, gdb doesn't use it + <tschwinge> hacklu: That is a good question -- I can't answer it off-hand, + but it might be possible (by setting the tracing flag, and such things). + Perhaps it's just a GDB bug, which omits to do that. Perhaps just a + one-line code change, perhaps not. That's a new bug (?) report that we + may want to have a look at later on. + <tschwinge> hacklu: But also note, this new problem is not really related + to your gdbserver work -- but of course you're fine to have a look at it + if you'd like to. + <hacklu> I just to ask for whether this is a normal behavior. this is + related to my gdbserver work, as gdbserver also need to attach a running + process... + <braunr> gdbserver can start a process just like gdb does + <braunr> you may want to focus on that first + <tschwinge> Yes. + <tschwinge> Attaching to processes that are already running is, I think, + always more complicated compared to the case where GDB/gdbserver has + complete control about the inferior right from the beginning. + <hacklu> yes, I am only focus on start one. the attach way I haven't + research now. + <tschwinge> hacklu: That's totally fine. You can just say that attaching + to processes is not supported yet. + <hacklu> that's sound good:) + <tschwinge> Ther will likely be more things in gdbserver that you won't be + able to easily support, so it's fine to do it step-by-step. + <tschwinge> And then later add more features incrementally. + <tschwinge> That's also easier for reviewing the patches. + + <hacklu> and one more question I have ask yestoday. what is the rpctrace + output (pid-1) mean? + <tschwinge> hacklu: Another thing I can't tell off-hand. I'll try to look + it up. + <teythoon> hacklu, tschwinge: my theory is that it is in fact an error + message, maybe the proc server did not now a pid for the task + <braunr> hacklu: utsl + <hacklu> tschwinge: for saving your time, I will look the code myself, I + don;t think this is a real hard question need you to help me by reading + the source code. + <tschwinge> teythoon, hacklu: Yes, from a quick inspection it looks like + task2pid returning a -1 PID -- but I can't tell yet what that is supposed + to mean, if it's an actualy bug, or just means there is no data + available, or similar. + <hacklu> braunr: utsl?? + <tschwinge> hacklu: http://www.catb.org/~esr/jargon/html/U/UTSL.html + <hacklu> tschwinge: thank you. braunr like say abbreviation which I can't + google out. + <tschwinge> hacklu: Again, if this affects your work, it is fine to have a + look at that presumed rpctrace problem, if not, it is fine to have a look + at it if you'd like to, and otherwise, we'll file it as a possible bug to + be looked at laster. + <tschwinge> hacklu: Now you learned that one. :-) + <hacklu> tschwinge: ok , this doesn't affect me now. If I have time I will + figure out it. + + <teythoon> btw, what about the copyright assignment process? + <tschwinge> teythoon, hacklu: You still haven't heard from the FSF about + your copyright assignments? What's the latest you have heard? + <hacklu> tschwinge: I have wrote a emali to ask for that, but no reply. + <teythoon> tschwinge: last and only response I got was on July 1st, the + last ping with explicit request for confirmation was on July the 12th + <tschwinge> hacklu: When did you send this email? + <hacklu> tschwinge: last week. + <tschwinge> teythoon: I suggest you send another inquiry, and please put me + in CC. And if there'S no answer within a couple days (well, I'm away + until Monday...), I'll follow up. + <tschwinge> hacklu: Likewise for you; depending on when exactly ;-) you + sent the last email. (Always allow for a few days until you exect an + answer, but if nothing happend within a week for such rather simple + administrative tasks, better ask again, unfrotunately.) + <hacklu> tschwinge:ok , I will email more + + <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 :) + + <youpi> how about the copyright assignments? did hacklu or teythoon receive + any answer? + <teythoon> youpi: I did, the copyright clerk told me that he finally got my + papers and that everything is in order now + <youpi> few! + <youpi> s/f/ph + <youpi> teythoon: you mean all steps are supposed to be done now, or is he + doing the last steps? I don't see your name in the copyright folder yet + <teythoon> youpi: well, he said that he had the papers and they are about + to be signed + <youpi> teythoon: ok, so it's not finished, that's why your name is not on + the list yet + <youpi> this paper stuff is really a pain + <hacklu> youpi: I haven't got any answer from FSF now. + <youpi> did you ping them recently? + <hacklu> I have pinged 2 week ago. + <hacklu> what you mean of ping? I just write an email to him. Is it enough? + <youpi> yes + + +# IRC, freenode, #hurd, 2013-08-12 + + <hacklu> hi, this is my weekly report + http://hacklu.com/blog/gsoc-weekly-report8-168/ . sorry for so late. + + <youpi> hacklu: it seems we misunderstood ourselves last week, I meant to + start from the existing gdbserver implementation + <youpi> but never mind :) + <youpi> starting from the lynxos version was a good idea + <hacklu> youpi: em... yeah, the lynxos port is so clean and simple. + + <hacklu> youpi: aha, the "Remote connection closed" problem has been fixed + after I add a init_registers_i386() and set the structure target_desc. + <hacklu> but I don't get understand with the structure target_desc. I only + know it is auto-generated which configured by the configure.srv. + <tschwinge> Hi! + <tschwinge> hacklu: In gdbserver, you should definitely re-use existing + infrastructure, especially anything that deals with the + protocol/communication with GDB (that is, server.c and its support + files). + <tschwinge> hacklu: Then, for the x86 GNU Hurd port, it should be + implemented in the same way as an existing port. The Linux port is the + obvious choice, of course, but it is also fine to begin with something + simpler (like the LynxOS port you've chosen), and then we can still add + more features later on. That is a very good approach actually. + <tschwinge> hacklu: The x86 GNU Hurd support will basically consist of + three pieces -- exactly as with GDB's native x86 GNU Hurd port: x86 + processor specific (tge existing gdbserver/i386-low.c etc. -- shouldn't + need any modifications (hopefully)), GNU Hurd specific + (gdbserver/gnu-hurd-low.c (or similar)), and x86 GNU Hurd specific + (gdbserver/gnu-hurd-x86-low.c (or similar)). + <tschwinge> s%tge%the + <hacklu> tschwinge: now I have only add a file named gnu-low.c, I should + move some part to the file gnu-i386-low.c I think. + <tschwinge> hacklu: That's fine for the moment. We can move the parts + later (everything with 86 in its name, probably). + <hacklu> that's ok. + <hacklu> tschwinge: Can I copy code from gnu-nat.c to + gdbserver/gnu-hurd-low.c? I think the two file will have many same code. + <tschwinge> hacklu: That's correct. Ideally, the code should be shared + (for example, in a file in common/), but that's an ongoing discussion in + GDB, for other duplicated code. So, for the moment, it is fine to copy + the parts you need. + <tschwinge> hacklu: Oh, but it may be a good idea to add a comment to the + source code, where it is copied from. + <hacklu> maybe I can do a common-part just for hurd gdb port. + <tschwinge> That should make it easier later on, to consolidate the + duplicated code into one place. + <tschwinge> Or you can do that, of course. If it's not too difficult to + do? + <hacklu> I think at the begining it is not difficult. But when the + gdbserver code grow, the difference with gdb is growing either. That will + be too many #if else. + <tschwinge> I think we should check with the GDB maintainers, what they + suggest. + <tschwinge> hacklu: Please send an email To: <gdb@sourceware.org> Cc: + <lgustavo@codesourcery.com>, <thomas@codesourcery.com>, and ask about + this: you need to duplicate code that already exists in gnu-nat.c for new + gdbserver port -- how to share code? + <hacklu> tschwinge: ok, I will send the email right now. + <hacklu> tschwinge: need I cc to hurd mail-list? + <tschwinge> hacklu: Not really for that questions, because that is a + question only relevant to the GDB source code itself. + <hacklu> tschwinge: got it. + +[[!message-id +"CAB8fV=jzv_rPHP3-HQVBA-pCNZNat6PNbh+OJEU7tZgQdKX3+w@mail.gmail.com"]]. + + +# IRC, freenode, #hurd, 2013-08-19 + +<http://hacklu.com/blog/gsoc-weekly-report9-172/>. + + <hacklu__> when and where is the best time and place to get the regitser + value in gdb? + <youpi> well, I'm not sure to understand the question + <youpi> you mean in the gdb source code, right? + <youpi> isn't it already done in gdb? + <youpi> probably similarly to i386? + <youpi> (linux i386 I mean) + <hacklu__> I don't find the fetch_register or relate function implement in + gnu-nat.c + <hacklu__> so I can't make decision how to implement this in gdbserver. + <youpi> it's in i386gnu-nat.c, isn't it? + <hacklu__> yeah. + <youpi> does that answer your issue? + <hacklu__> thank you. I am so stupid + + +# IRC, freenode, #hurd, 2013-08-26 + + < hacklu> hello everyone, this is my week + report. http://hacklu.com/blog/gsoc-weekly-report10-174/ + + < hacklu> btw, my FSF copyright assignment has been concepted. They guy + said, they have recived my mail for a while but forget to handle it. + + < hacklu> but now I face a new problem, when I typed the first continue + command, gdb will continue all the breakpoint, and the inferior will run + until normally exit. + + +# IRC, freenode, #hurd, 2013-08-30 + + <hacklu> tschwinge: hi, does gdb's attach feature work correctlly on Hurd? + <hacklu> on my hurd-box, the gdb can't attach to a running process, after a + attaching, when I continue, gdb complained "can't find pid 12345" + <teythoon> hacklu: attaching works, not sure why gdb is complaining + <hacklu> teythoon: yeah, it can attaching, but can't contine process. + <hacklu> in this case, the debugger is useless if it can't resume execution + <teythoon> hacklu: well, gdb on Linux reacts a little differently, but for + me attaching and then resuming works + <hacklu> teythoon: yes, gdb on linux works well. + <teythoon> % gdb --pid 21506 /bin/sleep + <teythoon> [...] + <teythoon> (gdb) c + <teythoon> Continuing. + <teythoon> warning: Can't wait for pid 21506: No child processes + <teythoon> # pkill -SIGILL sleep + <teythoon> warning: Pid 21506 died with unknown exit status, using SIGKILL. + <hacklu> yes. I used a sleep program to test too. + <teythoon> I believe that the warning and deficiencies with the signal + handling are b/c on Hurd the debuggee cannot be reparented to the + debugger + <hacklu> oh, I remembered, I have asked this before. + <tschwinge> Confirming that attaching to a process in __sleep -> __mach_msg + -> mach_msg_trap works fine, but then after »continue«, I see »warning: + Can't wait for pid 4038: No child processes« and three times »Can't fetch + registers from thread bogus thread id 1: No such thread« and the sleep + process exits (normally, I guess? -- interrupted "system call"). + <tschwinge> If detaching (exit GDB) instead, I see »warning: Can't modify + tracing state for pid 4041: No such process« and the sleep process exits. + <tschwinge> Attaching to and then issueing »continue« in a process that is + not currently in a mach_msg_trap (tested a trivial »while (1);«) seems to + work. + <tschwinge> hacklu: ^ + <hacklu> tschwinge: in my hurdbox, if I just attach a while(1), the system + is near down. nothing can happen, maybe my hardware is slow. + <hacklu> so I can only test on the sleep one. + <hacklu> my gdbserver doesn't support attach feature now. the other basic + feather has implement. I am doing test and review the code now. + <tschwinge> Great! :-) + <tschwinge> It is fine if attaching does not work currently -- can be added + later. + <hacklu> btw, How can I submit my code? put the patch in email directly? + <tschwinge> Did you already run the GDB testsuite using your gdbserver? + <hacklu> no, haven't yet + <tschwinge> Either that, or a Git branch to pull from. + <hacklu> I think I should do more review and test than I submit patches. + <tschwinge> hacklu: See [GDB]/gdb/testsuite/boards/native-gdbserver.exp + (and similar files) for how to run the GDB testsuite with gdbserver. + <hacklu> ok. + <tschwinge> But don't be disappointed if there are still a lot of failures, + etc. It'll already be great if some basic stuff works. + <hacklu> now it can set and remove breakpoint. show register, access + variables. + <tschwinge> ... which already is enogh for a lot of debugging sessions. + :-) + <hacklu> I will continue to make it more powerful. + <hacklu> :) + <tschwinge> Yes, but please first work on polishing the existing code, and + get it integrated upstream. That will be a great milestone. + <tschwinge> No doubt that GDB maintainers will have lots of comments about + proper formatting of the source code, and such things. Trivial, but will + take time to re-work and get right. + <hacklu> oh, I got it. I will give my pathch before this weekend. + <tschwinge> Then once your basic gdbserver is included, you can continue to + implement additional features, piece by piece. + <tschwinge> And then we can run the GDB testsuite with gdbserver and + compare that there are no regressions, etc. + <tschwinge> Heh, »before the weekend« -- that's soon. ;-) + <hacklu> honestly to say, most of the code is copyed from other files, I + haven't write too many code myself. + <tschwinge> Good -- this is what I hoped. Often, more time in software + development is spent on integrating existing things rathen than writing + new code. + <hacklu> but I have spent a lot of time to get known the code and to debug + it to work. + <tschwinge> Thzis is normal, and is good in fact: existing code has already + been tested and documented (in theory, at least...). + <tschwinge> Yes, that's expected too: when relying on/reusing existing + code, you first have to understand it, or at least its interfaces. Doing + that, you're sort of "mentally writing the existing code again". + <tschwinge> So, this sounds all fine. :-) + <hacklu> your words make me happy. + <hacklu> :) + <tschwinge> Well, I am, because this seems to be going well. + <hacklu> thank you. I am going to coding now~~ + + +# IRC, freenode, #hurd, 2013-09-02 + + <hacklu> hi, this is my weekly + report. http://hacklu.com/blog/gsoc-weekly-report11-181/ + + <hacklu> please give me any advice on how to use mig to generate stub-files + in gdbserver? + <braunr> hacklu: + http://darnassus.sceen.net/gitweb/rbraun/slabinfo.git/blob/HEAD:/Makefile + <hacklu> braunr: shouldnt' I work like this + https://github.com/hacklu/gdbserver/blob/gdbserver/gdb/config/i386/i386gnu.mh + ? + <braunr> hacklu: seems that you need server code + <braunr> other than that i don't see the difference + <hacklu> gdb use autoconf to generate the Makefile, and part from the *.mh + file, but in gdbserver, there is no .mh like files. + <braunr> hacklu: why can't you reuse /i386gnu.mh ? + <hacklu> braunr: question is that, there are something not need in + /i386gnu.mh. + <braunr> hacklu: like what ? + <hacklu> braunr: like fork-child.o msg_U.o core-regset.o + <braunr> hacklu: well, adjust the dependencies as you need + <braunr> hacklu: do you mean they become useless for gdbserver but are + useful for gdb ? + <hacklu> braunr: yes, so I need another one gnu.mh file. + <hacklu> braunr: but the gdbserver's configure doesn't have any *.mh file, + can I add the first one? + <braunr> or adjust the values of those variables depending on the building + mode + <braunr> maybe + <braunr> tschwinge is likely to better answer those questions + <hacklu> braunr: ok, I will wait for tschwinge's advice. + <luisgpm> hacklu, The gdb/config/ dir is for files related to the native + gdb builds, as opposed to a cross gdb that does not have any native bits + in it. In the latter, gdbserver will be used to touch the native layer, + and GDB will only guide gdbserver through the debugging session... + <luisgpm> hacklu, In case you haven't figured that out already. + <hacklu> luisgpm: I am not very clear with you. According to your words, I + shouldn't use gdb/config for gdbserver? + <luisgpm> hacklu, Correct. You should use configure.srv for gdbserver. + <luisgpm> hacklu, gdb/gdbserver/configure.srv that is. + <luisgpm> hacklu, gdb/configure.tgt for non-native gdb files... + <luisgpm> hacklu, and gdb/config for native gdb files. + <luisgpm> hacklu, The native/non-native separation for gdb is due to the + possibility of having a cross gdb. + <congzhang> what's srv file purpose? + <luisgpm> hacklu, gdbserver, on the other hand, is always native. + <luisgpm> Doing the target-to-object-files mapping. + <hacklu> how can I use configure.srv to config the MIG to generate + stub-files? + <luisgpm> What are stub-files in this context? + <hacklu> On Hurd, some rpc stub file are auto-gen by MIG with *.defs file + <braunr> luisgpm: c source code handling low level ipc stuff + <braunr> mig is the mach interface generator + <tschwinge> luisgpm, hacklu: If that is still helpful by now, in + <http://news.gmane.org/find-root.php?message_id=%3C87ppwqlgot.fsf%40kepler.schwinge.homeip.net%3E> + I described the MIG usage in GDB. (Which also states that ptrace is a + system call which it is not.) + <tschwinge> hacklu: For the moment, it is fine to indeed copy the rules + related to MIG/RPC stubs from gdb/config/i386/i386gnu.mh to a (possibly + new) file in gdbserver. Then, later, we should work out how to properly + share these, as with all the other code that is currently duplicated for + GDB proper and gdbserver. + <luisgpm> hacklu, tschwinge: If there is code gdbserver and native gdb can + use, feel free to put them inside gdb/common for now. + <tschwinge> hacklu, luisgpm: Right, that was the conclusion from + <http://news.gmane.org/find-root.php?message_id=%3CCAB8fV%3Djzv_rPHP3-HQVBA-pCNZNat6PNbh%2BOJEU7tZgQdKX3%2Bw%40mail.gmail.com%3E>. + <hacklu> tschwinge, luisgpm : ok, I got it. + <hacklu> tschwinge: sorry for haven't submit pathes yet, I will try to + submit my patch tomorrow. + +[[!message-id "CAB8fV=iw783uGF8sWyqJNcWR0j_jaY5XO+FR3TyPatMGJ8Fdjw@mail.gmail.com"]]. + + +# IRC, freenode, #hurd, 2013-09-06 + + <hacklu> If I want compile a file which is not in the current directory, + how should I change the Makefile. I have tried that obj:../foo.c, but the + foo.o will be in ../, not in the current directory. + <hacklu> As say, When I build gdbserver, I want to use [gdb]/gdb/gnu-nat.c, + How can I get the gnu-nat.o under gdbserver's directory? + <hacklu> tschwinge: ^^ + <tschwinge> Hi! + <tschwinge> hacklu: Heh, unexpected problem. + <tschwinge> hacklu: How is this handled for the files that are already in + gdb/common/? I think these would have the very same problem? + <hacklu> tschwinge: ah. + <hacklu> I got it + <tschwinge> I see, for example: + <tschwinge> ./gdb/Makefile.in:linux-btrace.o: + ${srcdir}/common/linux-btrace.c + <tschwinge> ./gdb/gdbserver/Makefile.in:linux-btrace.o: + ../common/linux-btrace.c $(linux_btrace_h) $(server_h) + <hacklu> If I have asked before, I won't use soft link to solve this. + <tschwinge> But isn't that what you've been trying? + <hacklu> when this, where the .o file go to? + <tschwinge> Yes, symlinks can't be used, because they're not available on + every (file) system GDB can be built on. + <tschwinge> I would assume the .o files to go into the current working + directory. + <tschwinge> Wonder why this didn't work for you. + <hacklu> in gdbserver/configure.srv, there is a srv_tgtobj="gnu_nat.c ..", + if I change the Makefile.in, it doesn't gdb's way. + <hacklu> So I can't use the variable srv_tgtobj? + <tschwinge> That should be srv_tgtobj="gnu_nat.o [...]"? (Not .c.) + <hacklu> I have try this, srv_tgtobj="../gnu_nat.c", then the gnu_nat.o is + generate in the parent directory. + <hacklu> s/.c/.o + <hacklu> (wrong input) + <hacklu> For my understand now, I should set the srv_tgtobj="", and then + set the gnu_nat.o:../gnu_nat.c in the gdbserver/Makefile.in. right? + <tschwinge> Hmm, I thought you'd need both. + <tschwinge> Have you tried that? + <hacklu> no, haven't yet. I will try soon. + <hacklu> I have met an strange thing. I have this in Makefile, + i386gnu-nat.o:../i386gnu-nat.c $(CC) -c $(CPPFLAGS) $(INTERNAL_CFLAGS) $< + <hacklu> When make, it will complain that: no rules for target + i386gnu-nat.c + <hacklu> but I also have a line gnu-nat.o:../gnu-nat.c ../gnu-nat.h. this + works well. + <tschwinge> hacklu: Does it work if you use $(srcdir)/../i386gnu-nat.c + instead of ../i386gnu-nat.c? + <tschwinge> Or similar. + <hacklu> I have try this, i386gnu-nat.c: echo "" ; then it works. + <hacklu> (try $(srcdir) ing..) + <hacklu> make: *** No rule to make target `.../i386gnu-nat.c', needed by + `i386gnu-nat.o'. Stop. + <hacklu> seems no use. + <hacklu> tschwinge: I have found another thing, if I rename the + i386gnu-nat.o to other one, like i386gnu-nat2.o. It works! + + +# IRC, freenode, #hurd, 2013-09-07 + + <hacklu> hi, I have found many '^L' in gnu-nat.c, should I fix it or keep + origin? + <LarstiQ> hacklu: fix in what sense? + <hacklu> remove the line contains ^L + <LarstiQ> hacklu: see bottom of + http://www.gnu.org/prep/standards/standards.html#Formatting + <LarstiQ> hacklu: "Please use formfeed characters (control-L) to divide the + program into pages at logical places (but not within a function)." + <LarstiQ> hacklu: so unless a reason has come up to deviate from the gnu + coding standards, those ^L's are there by design + <hacklu> LarstiQ: Thank you! I always think that are some format error. I + am stupid. + <LarstiQ> hacklu: not stupid, you just weren't aware + * LarstiQ thought the same when he first encountered them + + +# IRC, freenode, #hurd, 2013-09-09 + + <youpi> hacklu_, hacklu__: I don't know what tschwinge thinks, but I guess + you should work with upstream on integration of your existing work, this + is part of the gsoc goal: submitting one's stuff to projects + <tschwinge> youpi: Which is what we're doing (see the patches recently + posted). :-) + <youpi> ok + <hacklu__> youpi: I always doing what you have suggest. :) + <hacklu> I have asked in my new mail, I want to ask at here again. Should + I change the gdb use lwp filed instead of tid field? There are + <hacklu> too many functions use tid. Like + <hacklu> named tid in the structure proc also. + <hacklu> make_proc(),inf_tid_to_thread(),ptid_build(), and there is a field + <hacklu> (sorry for the bad \n ) + <hacklu> and this is my weekly + report. http://hacklu.com/blog/gsoc-weekly-report12-186/ + <hacklu> And in Pedro Alves's reply, he want me to integration only one + back-end for gdb and gdbserver. but the struct target_obs are just + decalre different in both of the two. How can I integrate this? or I got + the mistaken understanding? + <hacklu> tschwinge: ^^ + <tschwinge> hacklu: I will take this to email, so that Pedro et al. can + comment, too. + <tschwinge> hacklu: I'm not sure about your struct target_ops question. + Can you replay to Pedro's email to ask about this? + <hacklu> tschwinge: ok. + <tschwinge> hacklu: I have sent an email about the LWP/TID question. + <hacklu> tschwinge: Thanks for your email, now I know how to fix the + LWP/TID for this moment. + <tschwinge> hacklu: Let's hope that Pedro also is fine with this. :-) + <hacklu> tschwinge: BTW, I have a question, if we just use a locally + auto-generated number to distignuish threads in a process, How can we do + that? + <hacklu> How can we know which thread throwed the exception? + <hacklu> I haven't thought about this before. + <tschwinge> hacklu: make_proc sets up a mapping from Mach threads to GDB's + TIDs. And then, for example inf_tid_to_thread is used to look that up. + <hacklu> tschwinge: oh, yeah. that is. + + +# IRC, freenode, #hurd, 2013-09-16 + + <tschwinge> hacklu: Even when waiting for Pedro (and me) to comment, I + guess you're not out of work, but can continue in parallel with other + things, or improve the patch? + <hacklu> tschwinge: honestly to say, these days I am out of work T_T after + I have update the patch. + <hacklu> I am not sure how to improve the patch beyond your comment in the + email. I have just run some testcase and nothing others. + <tschwinge> hacklu: I have not yet seen any report on the GDB testsuite + results using your gdbserver port (see + gdb/testsuite/boards/native-gdbserver.exp). :-D + <hacklu> question is, the resule of that testcase is just how many pass how + many not pass. + <hacklu> and I am not sure whether need to give this information. + <tschwinge> Just as a native run of GDB's testsuite, this will create *.sum + and *.log files, and these you can diff to those of a native run of GDB's + testsuite. + <hacklu> https://paste.debian.net/41066/ this is my result + === gdb Summary === + + # of expected passes 15573 + # of unexpected failures 609 + # of unexpected successes 1 + # of expected failures 31 + # of known failures 57 + # of unresolved testcases 6 + # of untested testcases 47 + # of unsupported tests 189 + /home/hacklu/code/gdb/gdb/testsuite/../../gdb/gdb version 7.6.50.20130619-cvs -nw -nx -data-directory /home/hacklu/code/gdb/gdb/testsuite/../data-directory + + make[3]: *** [check-single] Error 1 + make[3]: Leaving directory `/home/hacklu/code/gdb/gdb/testsuite' + make[2]: *** [check] Error 2 + make[2]: Leaving directory `/home/hacklu/code/gdb/gdb' + make[1]: *** [check-gdb] Error 2 + make[1]: Leaving directory `/home/hacklu/code/gdb' + make: *** [do-check] Error 2 + <hacklu> I got a make error so I don't get the *.sum and *.log file. + <tschwinge> Well, that should be fixed then? + <tschwinge> hacklu: When does university start again for you? + <hacklu> My university have start a week ago. + <hacklu> but I will fix this, + <tschwinge> Oh, OK. So you won't have too much time anymore for GDB/Hurd + work? + <hacklu> it is my duty to finish my work. + <hacklu> time is not the main problem to me, I will shedule it for myself. + <tschwinge> hacklu: Thanks! Of course, we'd be very happy if you stay with + us, and continue working on this project (or another one)! :-D + <hacklu> I also thanks all of you who helped me and mentor me to improve + myself. + <hacklu> then, what the next I can do is that fix the testcase failed? + <tschwinge> hacklu: It's been our pleasure! + <tschwinge> hacklu: A comparison of the GDB testsuite results for a native + and gdbserver run would be good to get an understanding of the current + status. + <hacklu> ok, I will give this comparison soon. BTW,should I compare the + native gdb result with the one before my patch + <tschwinge> You mean compare the native run before and after your patch? + Yes, that also wouldn't hurt to do, to show that your patch doesn't + introduce any regressions to the native GDB port. + <hacklu> ok, beside this I should compare the native gdb with gdbserver ? + <tschwinge> Yes. + <hacklu> beside this, what I can do more? + <tschwinge> No doubt, there will be differences between the native and + gdbserver test runs -- the goal is to reduce these. (This will probably + translate to: implement more stuff for the Hurd port of gdbserver.) + <hacklu> ok, I know it. Start it now + <tschwinge> As time permits. :-) + <hacklu> It's ok. :) + + +# IRC, freenode, #hurd, 2013-09-23 + + <hacklu_> I have to go out in a few miniutes, will be back at 8pm. I am + sorry to miss the meeting this week, I will finishi my report soon. + <hacklu_> tschwinge, youpi ^^ |