* target_find_description question @ 2008-09-02 23:49 Ulrich Weigand 2008-09-04 12:12 ` Daniel Jacobowitz 0 siblings, 1 reply; 11+ messages in thread From: Ulrich Weigand @ 2008-09-02 23:49 UTC (permalink / raw) To: drow; +Cc: gdb-patches Hi Dan, in testing the Cell debugger, I came across the question how to handle target_find_description for native (inf-ptrace) targets. As I understand it, the idea is to determine the target description *before* any access to target registers happens. However, for inf-ptrace targets this is not the case: inf_ptrace_create_inferior calls fork_inferior, which call the inf_ptrace_him callback, which calls startup_inferior. That latter function now calls wait_for_inferior. This does not only do a target_wait, however, but does the full handle_inferior_event processing -- which at the very least reads the PC register (for decr_pc_after_break processing and to set stop_pc). This happens *before* target_find_description is called (from post_create_inferior). Now, this ususally doesn't matter much, because the PC tends not to be changed by target descriptions -- and even if it were, this would just mean we got (and igored) and invalid value for stop_pc on startup. However, with the multi-arch debugger, this can actually mean that the ppc_linux_fetch_inferior_registers routine gets called with a regcache architecture that is not even PowerPC! This is a problem in that subroutines of ppc_linux_fetch_inferior_registers will do a gdbarch_tdep () on that architecture and blindly access it as if it were the PowerPC version, causing random memory accesses. In fact, I guess you could even construct cases where that happens with today's mainline GDB when built with secondary target support: suppose you debug some non-PowerPC remote target, detach from it (leaving current_gdbarch pointing to that other architecture), and then attach to a native PowerPC process in the same GDB session. Right now I've solved the invalid memory access by a simple check in ppc_linux_fetch_inferior_registers whether the regcache is actually for PowerPC, and just silently returning if it isn't. But it seems a proper fix should be rather to call target_find_description earlier, indeed before any register access happens. Unfortunately this is a bit awkward as it would mean that either startup_inferior can no longer just call wait_for_inferior, or else that there would need to be special handling for this case in wait_for_inferior ... Do you have any suggestions how best to handle this? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: target_find_description question 2008-09-02 23:49 target_find_description question Ulrich Weigand @ 2008-09-04 12:12 ` Daniel Jacobowitz 2008-09-04 19:17 ` Ulrich Weigand 0 siblings, 1 reply; 11+ messages in thread From: Daniel Jacobowitz @ 2008-09-04 12:12 UTC (permalink / raw) To: Ulrich Weigand; +Cc: gdb-patches On Wed, Sep 03, 2008 at 01:47:56AM +0200, Ulrich Weigand wrote: > Hi Dan, > > in testing the Cell debugger, I came across the question how to handle > target_find_description for native (inf-ptrace) targets. As I understand > it, the idea is to determine the target description *before* any access > to target registers happens. That's right. The remote target used to have a similar problem to the one you describe, and before final merge I redid bits of it in order to move target description reads earlier. > But it seems a proper fix should be rather to call target_find_description > earlier, indeed before any register access happens. Unfortunately this > is a bit awkward as it would mean that either startup_inferior can no > longer just call wait_for_inferior, or else that there would need to > be special handling for this case in wait_for_inferior ... > > Do you have any suggestions how best to handle this? target_find_description currently has a global flag, target_desc_fetched, which means that reading the description multiple times is harmless. The flag will need to become per-target in a multi-target GDB, of course. So it's OK to call target_find_description by hand at an earlier point, before any register access. Unfortunately we're supposed to do that when the target is stopped. Otherwise, any check which attempts to read the registers or aux vector will not work. I suppose the easiest thing to do would be to call target_find_description right before handle_inferior_event, and rely on target_desc_fetched to prevent duplicate work. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: target_find_description question 2008-09-04 12:12 ` Daniel Jacobowitz @ 2008-09-04 19:17 ` Ulrich Weigand 2008-09-04 21:52 ` Daniel Jacobowitz 0 siblings, 1 reply; 11+ messages in thread From: Ulrich Weigand @ 2008-09-04 19:17 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb-patches Daniel Jacobowitz wrote: > I suppose the easiest thing to do would be to call > target_find_description right before handle_inferior_event, and rely > on target_desc_fetched to prevent duplicate work. Unfortunately, it turns out this doesn't work. Or rather, it works too well: target_find_description is called after the first stop, and determines target properties -- while the inferior process is still executing the shell we're using to start up the real inferior! So it'll detect e.g. a 32-bit inferior because the shell is 32-bit, even though the real inferior is a 64-bit application ... I guess we do need to defer target_find_description until after the real inferior is started. However, we then have the problem of how to handle those register/memory accessed in the mean time. Maybe we can change handle_inferior_event to not do any PC processing if stop_soon is set? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: target_find_description question 2008-09-04 19:17 ` Ulrich Weigand @ 2008-09-04 21:52 ` Daniel Jacobowitz 2008-09-04 22:12 ` Pedro Alves 0 siblings, 1 reply; 11+ messages in thread From: Daniel Jacobowitz @ 2008-09-04 21:52 UTC (permalink / raw) To: Ulrich Weigand; +Cc: gdb-patches On Thu, Sep 04, 2008 at 09:16:33PM +0200, Ulrich Weigand wrote: > Daniel Jacobowitz wrote: > > > I suppose the easiest thing to do would be to call > > target_find_description right before handle_inferior_event, and rely > > on target_desc_fetched to prevent duplicate work. > > Unfortunately, it turns out this doesn't work. Or rather, it works > too well: target_find_description is called after the first stop, > and determines target properties -- while the inferior process is > still executing the shell we're using to start up the real inferior! Whoops. I didn't think of that. > So it'll detect e.g. a 32-bit inferior because the shell is 32-bit, > even though the real inferior is a 64-bit application ... > > I guess we do need to defer target_find_description until after the > real inferior is started. However, we then have the problem of how > to handle those register/memory accessed in the mean time. Shouldn't accessing the shell's registers always be a bug, admitted one that we already have? We don't have symbols for it, we don't support breakpoints in it, et cetera. We used to have some global information about the number of expected traps, but now it's local. > Maybe we can change handle_inferior_event to not do any PC processing > if stop_soon is set? I don't think that will work, e.g. solib-irix.c and various other solib modules run expecting to hit a breakpoint. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: target_find_description question 2008-09-04 21:52 ` Daniel Jacobowitz @ 2008-09-04 22:12 ` Pedro Alves 2008-09-04 22:27 ` Pedro Alves 0 siblings, 1 reply; 11+ messages in thread From: Pedro Alves @ 2008-09-04 22:12 UTC (permalink / raw) To: gdb-patches; +Cc: Daniel Jacobowitz, Ulrich Weigand On Thursday 04 September 2008 22:51:32, Daniel Jacobowitz wrote: > I don't think that will work, e.g. solib-irix.c and various other > solib modules run expecting to hit a breakpoint. Isn't that a breakpoint in the real inferior, not the shell, and expected *after* stop_soon is reset (after create_inferior), in post_create_inferior/solib_create_inferior_hook? -- Pedro Alves ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: target_find_description question 2008-09-04 22:12 ` Pedro Alves @ 2008-09-04 22:27 ` Pedro Alves 2008-09-05 0:00 ` [patch, rfc] " Ulrich Weigand 0 siblings, 1 reply; 11+ messages in thread From: Pedro Alves @ 2008-09-04 22:27 UTC (permalink / raw) To: gdb-patches; +Cc: Daniel Jacobowitz, Ulrich Weigand Sorry, hit reply too soon. On Thursday 04 September 2008 23:12:10, Pedro Alves wrote: > On Thursday 04 September 2008 22:51:32, Daniel Jacobowitz wrote: > > I don't think that will work, e.g. solib-irix.c and various other > > solib modules run expecting to hit a breakpoint. > > Isn't that a breakpoint in the real inferior, not the shell, and > expected *after* stop_soon is reset (after create_inferior), in > post_create_inferior/solib_create_inferior_hook? I meant to suggest un-overload STOP_QUIETLY, and split it in two, at the "and" below: "STOP_QUIETLY is used when running in the shell before the child program has been exec'd and when running through shared library loading." -- Pedro Alves ^ permalink raw reply [flat|nested] 11+ messages in thread
* [patch, rfc] Re: target_find_description question 2008-09-04 22:27 ` Pedro Alves @ 2008-09-05 0:00 ` Ulrich Weigand 2008-09-05 2:40 ` Daniel Jacobowitz ` (3 more replies) 0 siblings, 4 replies; 11+ messages in thread From: Ulrich Weigand @ 2008-09-05 0:00 UTC (permalink / raw) To: Pedro Alves, drow; +Cc: gdb-patches Pedro Alves wrote. > On Thursday 04 September 2008 23:12:10, Pedro Alves wrote: > > On Thursday 04 September 2008 22:51:32, Daniel Jacobowitz wrote: > > > I don't think that will work, e.g. solib-irix.c and various other > > > solib modules run expecting to hit a breakpoint. > > > > Isn't that a breakpoint in the real inferior, not the shell, and > > expected *after* stop_soon is reset (after create_inferior), in > > post_create_inferior/solib_create_inferior_hook? > > I meant to suggest un-overload STOP_QUIETLY, and split it in two, > at the "and" below: > > "STOP_QUIETLY is used when running in the shell before the child > program has been exec'd and when running through shared > library loading." At this point it seems a mistake to try to re-use wait_for_inferior for the startup sequence in the first place. Most of what this cares about cannot ever happen during startup, and some of the remaining actions are actively harmful (accessing registers / memory). I've tried to strip down the wait_for_inferior and resume calls done by startup_inferior to the minimum that is actually needed for startup, and the result looks pretty straigtforward, and boils down to mostly using target_wait and target_resume directly. In addition, this has some further benefits: - We can now properly handle cases where the inferior dies while in the shell (the FIXME in the old startup_inferior code) - The treat_exec_as_sigtrap argument to handle_inferior_event is no longer used and could be removed (not part of this patch) As startup_inferior no longer calls init_wait_for_inferior, I've moved this to run_command_1 (which used to call init_wait_for_inferior indirectly via kill_if_already_running, but not if the program was already killed). This means that kill_if_already_running no longer needs to call it (nor does it need to call no_shared_libraries, which is now always called from target_pre_inferior.) Tested on amd64-linux with no regressions. What do you think? Bye, Ulrich ChangeLog: * fork-child.c (startup_inferior): Use target_wait and target_resume directly instead of calling wait_for_inferior / resume. * infcmd.c (kill_if_already_running): Do not call no_shared_libraries or init_wait_for_inferior. (run_command_1): Call init_wait_for_inferior. diff -urNp gdb-orig/gdb/fork-child.c gdb-head/gdb/fork-child.c --- gdb-orig/gdb/fork-child.c 2008-05-25 18:19:22.000000000 +0200 +++ gdb-head/gdb/fork-child.c 2008-09-05 01:35:03.000000000 +0200 @@ -422,21 +422,67 @@ startup_inferior (int ntraps) if (exec_wrapper) pending_execs++; - clear_proceed_status (); - - init_wait_for_inferior (); - while (1) { - /* Make wait_for_inferior be quiet. */ - stop_soon = STOP_QUIETLY; - wait_for_inferior (1); - if (stop_signal != TARGET_SIGNAL_TRAP) + int resume_signal = TARGET_SIGNAL_0; + ptid_t resume_ptid; + + struct target_waitstatus ws; + memset (&ws, 0, sizeof (ws)); + resume_ptid = target_wait (pid_to_ptid (-1), &ws); + + /* Mark all threads non-executing. */ + set_executing (pid_to_ptid (-1), 0); + + /* In all-stop mode, resume all threads. */ + if (!non_stop) + resume_ptid = pid_to_ptid (-1); + + switch (ws.kind) + { + case TARGET_WAITKIND_IGNORE: + case TARGET_WAITKIND_SPURIOUS: + case TARGET_WAITKIND_LOADED: + case TARGET_WAITKIND_FORKED: + case TARGET_WAITKIND_VFORKED: + case TARGET_WAITKIND_SYSCALL_ENTRY: + case TARGET_WAITKIND_SYSCALL_RETURN: + /* Ignore gracefully during startup of the inferior. */ + break; + + case TARGET_WAITKIND_SIGNALLED: + target_terminal_ours (); + target_mourn_inferior (); + error (_("During startup program terminated with signal %s, %s."), + target_signal_to_name (ws.value.sig), + target_signal_to_string (ws.value.sig)); + return; + + case TARGET_WAITKIND_EXITED: + target_terminal_ours (); + target_mourn_inferior (); + if (ws.value.integer) + error (_("During startup program exited with code %d."), + ws.value.integer); + else + error (_("During startup program exited normally.")); + return; + + case TARGET_WAITKIND_EXECD: + /* Handle EXEC signals as if they were SIGTRAP signals. */ + xfree (ws.value.execd_pathname); + resume_signal = TARGET_SIGNAL_TRAP; + break; + + case TARGET_WAITKIND_STOPPED: + resume_signal = ws.value.sig; + break; + } + + if (resume_signal != TARGET_SIGNAL_TRAP) { - /* Let shell child handle its own signals in its own way. - FIXME: what if child has exited? Must exit loop - somehow. */ - resume (0, stop_signal); + /* Let shell child handle its own signals in its own way. */ + target_resume (resume_ptid, 0, resume_signal); } else { @@ -461,10 +507,10 @@ startup_inferior (int ntraps) if (--pending_execs == 0) break; - resume (0, TARGET_SIGNAL_0); /* Just make it go on. */ + /* Just make it go on. */ + target_resume (resume_ptid, 0, TARGET_SIGNAL_0); } } - stop_soon = NO_STOP_QUIETLY; } /* Implement the "unset exec-wrapper" command. */ diff -urNp gdb-orig/gdb/infcmd.c gdb-head/gdb/infcmd.c --- gdb-orig/gdb/infcmd.c 2008-08-22 03:25:28.000000000 +0200 +++ gdb-head/gdb/infcmd.c 2008-09-05 01:02:02.000000000 +0200 @@ -464,8 +464,6 @@ kill_if_already_running (int from_tty) Start it from the beginning? ")) error (_("Program not restarted.")); target_kill (); - no_shared_libraries (NULL, from_tty); - init_wait_for_inferior (); } } @@ -481,6 +479,8 @@ run_command_1 (char *args, int from_tty, dont_repeat (); kill_if_already_running (from_tty); + + init_wait_for_inferior (); clear_breakpoint_hit_counts (); /* Clean up any leftovers from other runs. Some other things from -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, rfc] Re: target_find_description question 2008-09-05 0:00 ` [patch, rfc] " Ulrich Weigand @ 2008-09-05 2:40 ` Daniel Jacobowitz 2008-09-05 13:11 ` Pedro Alves ` (2 subsequent siblings) 3 siblings, 0 replies; 11+ messages in thread From: Daniel Jacobowitz @ 2008-09-05 2:40 UTC (permalink / raw) To: Ulrich Weigand; +Cc: Pedro Alves, gdb-patches On Fri, Sep 05, 2008 at 01:59:29AM +0200, Ulrich Weigand wrote: > ChangeLog: > > * fork-child.c (startup_inferior): Use target_wait and target_resume > directly instead of calling wait_for_inferior / resume. > > * infcmd.c (kill_if_already_running): Do not call no_shared_libraries > or init_wait_for_inferior. > (run_command_1): Call init_wait_for_inferior. I like this a lot, though I'd like Pedro's opinion too. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, rfc] Re: target_find_description question 2008-09-05 0:00 ` [patch, rfc] " Ulrich Weigand 2008-09-05 2:40 ` Daniel Jacobowitz @ 2008-09-05 13:11 ` Pedro Alves 2008-09-06 1:55 ` Joel Brobecker 2008-09-11 16:13 ` Ulrich Weigand 3 siblings, 0 replies; 11+ messages in thread From: Pedro Alves @ 2008-09-05 13:11 UTC (permalink / raw) To: gdb-patches; +Cc: Ulrich Weigand, drow On Friday 05 September 2008 00:59:29, Ulrich Weigand wrote: > In addition, this has some further benefits: > - We can now properly handle cases where the inferior dies while in the > shell (the FIXME in the old startup_inferior code) > - The treat_exec_as_sigtrap argument to handle_inferior_event is no longer > used and could be removed (not part of this patch) Of course, a specific stop_soon flag for startup/going through the shell would also make it possible to do this in handle_inferior_event, but indeed, it would be more complicated. > Tested on amd64-linux with no regressions. > > What do you think? I like it. Notice that there are fork-child targets that handle this even at a lower level, within target_wait (see gnu-nat.c). -- Pedro Alves ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, rfc] Re: target_find_description question 2008-09-05 0:00 ` [patch, rfc] " Ulrich Weigand 2008-09-05 2:40 ` Daniel Jacobowitz 2008-09-05 13:11 ` Pedro Alves @ 2008-09-06 1:55 ` Joel Brobecker 2008-09-11 16:13 ` Ulrich Weigand 3 siblings, 0 replies; 11+ messages in thread From: Joel Brobecker @ 2008-09-06 1:55 UTC (permalink / raw) To: Ulrich Weigand; +Cc: Pedro Alves, drow, gdb-patches > I've tried to strip down the wait_for_inferior and resume calls done by > startup_inferior to the minimum that is actually needed for startup, and > the result looks pretty straigtforward, and boils down to mostly using > target_wait and target_resume directly. Looks like a nice solution to the problem. > - The treat_exec_as_sigtrap argument to handle_inferior_event is no longer > used and could be removed (not part of this patch) I would love to see that parameter go. I wasn't entirely happy when I introduced it. -- Joel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [patch, rfc] Re: target_find_description question 2008-09-05 0:00 ` [patch, rfc] " Ulrich Weigand ` (2 preceding siblings ...) 2008-09-06 1:55 ` Joel Brobecker @ 2008-09-11 16:13 ` Ulrich Weigand 3 siblings, 0 replies; 11+ messages in thread From: Ulrich Weigand @ 2008-09-11 16:13 UTC (permalink / raw) To: gdb-patches; +Cc: Pedro Alves, drow, brobecker > * fork-child.c (startup_inferior): Use target_wait and target_resume > directly instead of calling wait_for_inferior / resume. > > * infcmd.c (kill_if_already_running): Do not call no_shared_libraries > or init_wait_for_inferior. > (run_command_1): Call init_wait_for_inferior. I've checked this in now. Updated patch is appended below. Bye, Ulrich Index: gdb/fork-child.c =================================================================== RCS file: /cvs/src/src/gdb/fork-child.c,v retrieving revision 1.43 diff -c -p -r1.43 fork-child.c *** gdb/fork-child.c 8 Sep 2008 21:51:18 -0000 1.43 --- gdb/fork-child.c 11 Sep 2008 14:49:49 -0000 *************** startup_inferior (int ntraps) *** 428,451 **** if (exec_wrapper) pending_execs++; - clear_proceed_status (); - - init_wait_for_inferior (); - while (1) { ! struct thread_info *tp; ! /* Make wait_for_inferior be quiet. */ ! stop_soon = STOP_QUIETLY; ! wait_for_inferior (1); ! tp = inferior_thread (); ! if (tp->stop_signal != TARGET_SIGNAL_TRAP) { ! /* Let shell child handle its own signals in its own way. ! FIXME: what if child has exited? Must exit loop ! somehow. */ ! resume (0, tp->stop_signal); } else { --- 428,494 ---- if (exec_wrapper) pending_execs++; while (1) { ! int resume_signal = TARGET_SIGNAL_0; ! ptid_t resume_ptid; ! ! struct target_waitstatus ws; ! memset (&ws, 0, sizeof (ws)); ! resume_ptid = target_wait (pid_to_ptid (-1), &ws); ! ! /* Mark all threads non-executing. */ ! set_executing (pid_to_ptid (-1), 0); ! ! /* In all-stop mode, resume all threads. */ ! if (!non_stop) ! resume_ptid = pid_to_ptid (-1); ! ! switch (ws.kind) ! { ! case TARGET_WAITKIND_IGNORE: ! case TARGET_WAITKIND_SPURIOUS: ! case TARGET_WAITKIND_LOADED: ! case TARGET_WAITKIND_FORKED: ! case TARGET_WAITKIND_VFORKED: ! case TARGET_WAITKIND_SYSCALL_ENTRY: ! case TARGET_WAITKIND_SYSCALL_RETURN: ! /* Ignore gracefully during startup of the inferior. */ ! break; ! ! case TARGET_WAITKIND_SIGNALLED: ! target_terminal_ours (); ! target_mourn_inferior (); ! error (_("During startup program terminated with signal %s, %s."), ! target_signal_to_name (ws.value.sig), ! target_signal_to_string (ws.value.sig)); ! return; ! ! case TARGET_WAITKIND_EXITED: ! target_terminal_ours (); ! target_mourn_inferior (); ! if (ws.value.integer) ! error (_("During startup program exited with code %d."), ! ws.value.integer); ! else ! error (_("During startup program exited normally.")); ! return; ! ! case TARGET_WAITKIND_EXECD: ! /* Handle EXEC signals as if they were SIGTRAP signals. */ ! xfree (ws.value.execd_pathname); ! resume_signal = TARGET_SIGNAL_TRAP; ! break; ! ! case TARGET_WAITKIND_STOPPED: ! resume_signal = ws.value.sig; ! break; ! } ! if (resume_signal != TARGET_SIGNAL_TRAP) { ! /* Let shell child handle its own signals in its own way. */ ! target_resume (resume_ptid, 0, resume_signal); } else { *************** startup_inferior (int ntraps) *** 470,479 **** if (--pending_execs == 0) break; ! resume (0, TARGET_SIGNAL_0); /* Just make it go on. */ } } - stop_soon = NO_STOP_QUIETLY; } /* Implement the "unset exec-wrapper" command. */ --- 513,522 ---- if (--pending_execs == 0) break; ! /* Just make it go on. */ ! target_resume (resume_ptid, 0, TARGET_SIGNAL_0); } } } /* Implement the "unset exec-wrapper" command. */ Index: gdb/infcmd.c =================================================================== RCS file: /cvs/src/src/gdb/infcmd.c,v retrieving revision 1.210 diff -c -p -r1.210 infcmd.c *** gdb/infcmd.c 8 Sep 2008 22:10:20 -0000 1.210 --- gdb/infcmd.c 11 Sep 2008 14:49:49 -0000 *************** kill_if_already_running (int from_tty) *** 431,438 **** Start it from the beginning? ")) error (_("Program not restarted.")); target_kill (); - no_shared_libraries (NULL, from_tty); - init_wait_for_inferior (); } } --- 431,436 ---- *************** run_command_1 (char *args, int from_tty, *** 448,453 **** --- 446,453 ---- dont_repeat (); kill_if_already_running (from_tty); + + init_wait_for_inferior (); clear_breakpoint_hit_counts (); /* Clean up any leftovers from other runs. Some other things from -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2008-09-11 16:13 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-09-02 23:49 target_find_description question Ulrich Weigand 2008-09-04 12:12 ` Daniel Jacobowitz 2008-09-04 19:17 ` Ulrich Weigand 2008-09-04 21:52 ` Daniel Jacobowitz 2008-09-04 22:12 ` Pedro Alves 2008-09-04 22:27 ` Pedro Alves 2008-09-05 0:00 ` [patch, rfc] " Ulrich Weigand 2008-09-05 2:40 ` Daniel Jacobowitz 2008-09-05 13:11 ` Pedro Alves 2008-09-06 1:55 ` Joel Brobecker 2008-09-11 16:13 ` Ulrich Weigand
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox