Re: [PATCH 1/2] Port gdbserver to GNU/Hurd

[Yue Lu]

Hi,


On Wed, Sep 18, 2013 at 8:37 PM, Pedro Alves  wrote:
> On 09/12/2013 04:05 AM, Yue Lu wrote:
>
>> On Sat, Sep 7, 2013 at 2:53 AM, Pedro Alves  wrote:
>>> This is what I meant:
>>> https://sourceware.org/ml/gdb-patches/2013-09/msg00253.html
>>>
>>> I was thinking you'd wrap gnu_xfer_memory.
>>>
>>
>> I have study your patch,
>
> Thanks.  Did you try building gdb with it, and does the
> resulting GDB still work?

First thank you to tell me how to apply patch from email. I used
webmail of gmail and directly copy patch from the email which often
apply failed, then I had to patch line by line. Now I used mutt to
save email to mbox file then apply it, life changed! Before you told
me this, I never imaged this, so thanks!

I have test your patch, seems need a tiny fix. This is just a spelling
mistaken I think.

diff --git a/gdb/gnu-nat.c b/gdb/gnu-nat.c
index 07fe603..bc37bb8 100644
--- a/gdb/gnu-nat.c
+++ b/gdb/gnu-nat.c
@@ -2493,14 +2493,14 @@ gnu_xfer_memory (gdb_byte *readbuf, const char
*writebuf,
 {
   inf_debug (gnu_current_inf, "writing %s[%s] <-- %s",
 paddress (target_gdbarch (), memaddr), plongest (len),
-host_address_to_string (myaddr));
+host_address_to_string (writebuf));
   res = gnu_write_inferior (task, memaddr, writebuf, len);
 }
   else
 {
   inf_debug (gnu_current_inf, "reading %s[%s] --> %s",
 paddress (target_gdbarch (), memaddr), plongest (len),
-host_address_to_string (myaddr));
+host_address_to_string (readbuf));
   res = gnu_read_inferior (task, memaddr, readbuf, len);
 }
   if (res == 0)

After add this change, the gdb can work. But I have found a little
strange from the origin gdb.
When I set a breakpoint, then I run the inferior, after hit the
breakpoint, I just input next next until the inferior exit, then the
gdb will complain this:
[Inferior 1 (bogus thread id 0) exited normally]
Thread-specific breakpoint -37 deleted - thread 4 is gone.
Thread-specific breakpoint -38 deleted - thread 4 is gone.
Thread-specific breakpoint -39 deleted - thread 4 is gone.
Thread-specific breakpoint 0 deleted - thread 4 is gone.

I am not sure why this will output or is reasonable.

I got this output like this:
$./gdb gdb
$b main
$r
$n
$n
...
$q  (quit the debugged gdb)

-- 
Yue Lu (陆岳)

FAIL: gdb.base/nextoverexit.exp: next over exit (the program exited) (was: [PATCH 1/2] Port gdbserver to GNU/Hurd)

[Thomas Schwinge]

Hi!

On Thu, 19 Sep 2013 15:40:40 +0800, Yue Lu  wrote:
> On Wed, Sep 18, 2013 at 8:37 PM, Pedro Alves  wrote:
> > On 09/12/2013 04:05 AM, Yue Lu wrote:
> >
> >> On Sat, Sep 7, 2013 at 2:53 AM, Pedro Alves  wrote:
> >>> https://sourceware.org/ml/gdb-patches/2013-09/msg00253.html

> First thank you to tell me how to apply patch from email. I used
> webmail of gmail and directly copy patch from the email which often
> apply failed, then I had to patch line by line. Now I used mutt to
> save email to mbox file then apply it, life changed! Before you told
> me this, I never imaged this, so thanks!

Well, never assume that we'd use any convoluted procedures, such as
manually copying a patch's text.  ;-) Never hesitate to ask if you think
some process is too complicated to be done manually -- there will always
be someone who is happy to tell you about his creative solution.

> I have test your patch, seems need a tiny fix. This is just a spelling
> mistaken I think.

Right; I had come to the same conclusion, see my message in the other
thread.


> After add this change, the gdb can work. But I have found a little
> strange from the origin gdb.
> When I set a breakpoint, then I run the inferior, after hit the
> breakpoint, I just input next next until the inferior exit, then the
> gdb will complain this:
> [Inferior 1 (bogus thread id 0) exited normally]
> Thread-specific breakpoint -37 deleted - thread 4 is gone.
> Thread-specific breakpoint -38 deleted - thread 4 is gone.
> Thread-specific breakpoint -39 deleted - thread 4 is gone.
> Thread-specific breakpoint 0 deleted - thread 4 is gone.
> 
> I am not sure why this will output or is reasonable.
> 
> I got this output like this:
> $./gdb gdb
> $b main
> $r
> $n
> $n
> ...
> $q  (quit the debugged gdb)

"As of recently", I notice the same behavior for GDB on both x86
GNU/Linux and GNU/Hurd, also resulting in the gdb.base/nextoverexit.exp
test failing.  So, I don't think this is related to any Hurd
patches/behavior, but instead a general issue.

Quoting from the x86 GNU/Linux' gdb/testsuite/gdb.base2/gdb.log:

Breakpoint 1, main () at 
../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/nextoverexit.c:21
21exit (0);
(gdb) next
[Inferior 1 (process 25208) exited normally]
Thread-specific breakpoint -5 deleted - thread 1 is gone.
Thread-specific breakpoint -6 deleted - thread 1 is gone.
Thread-specific breakpoint -7 deleted - thread 1 is gone.
Thread-specific breakpoint 0 deleted - thread 1 is gone.
(gdb) FAIL: gdb.base/nextoverexit.exp: next over exit (the program exited)

Can others confirm this/is this a known issue?


Grüße,
 Thomas


pgp6ZND3CLoqz.pgp
Description: PGP signature

Re: FAIL: gdb.base/nextoverexit.exp: next over exit (the program exited)

[Pedro Alves]

On 09/19/2013 09:30 AM, Thomas Schwinge wrote:
> Hi!
> 
> On Thu, 19 Sep 2013 15:40:40 +0800, Yue Lu  wrote:
>> On Wed, Sep 18, 2013 at 8:37 PM, Pedro Alves  wrote:
>>> On 09/12/2013 04:05 AM, Yue Lu wrote:
>>>
 On Sat, Sep 7, 2013 at 2:53 AM, Pedro Alves  wrote:
> https://sourceware.org/ml/gdb-patches/2013-09/msg00253.html
> 
>> First thank you to tell me how to apply patch from email. I used
>> webmail of gmail and directly copy patch from the email which often
>> apply failed, then I had to patch line by line. Now I used mutt to
>> save email to mbox file then apply it, life changed! Before you told
>> me this, I never imaged this, so thanks!
> 
> Well, never assume that we'd use any convoluted procedures, such as
> manually copying a patch's text.  ;-) Never hesitate to ask if you think
> some process is too complicated to be done manually -- there will always
> be someone who is happy to tell you about his creative solution.
> 
>> I have test your patch, seems need a tiny fix. This is just a spelling
>> mistaken I think.
> 
> Right; I had come to the same conclusion, see my message in the other
> thread.
> 
> 
>> After add this change, the gdb can work. But I have found a little
>> strange from the origin gdb.
>> When I set a breakpoint, then I run the inferior, after hit the
>> breakpoint, I just input next next until the inferior exit, then the
>> gdb will complain this:
>> [Inferior 1 (bogus thread id 0) exited normally]
>> Thread-specific breakpoint -37 deleted - thread 4 is gone.
>> Thread-specific breakpoint -38 deleted - thread 4 is gone.
>> Thread-specific breakpoint -39 deleted - thread 4 is gone.
>> Thread-specific breakpoint 0 deleted - thread 4 is gone.
>>
>> I am not sure why this will output or is reasonable.
>>
>> I got this output like this:
>> $./gdb gdb
>> $b main
>> $r
>> $n
>> $n
>> ...
>> $q  (quit the debugged gdb)
> 
> "As of recently", I notice the same behavior for GDB on both x86
> GNU/Linux and GNU/Hurd, also resulting in the gdb.base/nextoverexit.exp
> test failing.  So, I don't think this is related to any Hurd
> patches/behavior, but instead a general issue.
> 
> Quoting from the x86 GNU/Linux' gdb/testsuite/gdb.base2/gdb.log:
> 
> Breakpoint 1, main () at 
> ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/nextoverexit.c:21
> 21exit (0);
> (gdb) next
> [Inferior 1 (process 25208) exited normally]
> Thread-specific breakpoint -5 deleted - thread 1 is gone.
> Thread-specific breakpoint -6 deleted - thread 1 is gone.
> Thread-specific breakpoint -7 deleted - thread 1 is gone.
> Thread-specific breakpoint 0 deleted - thread 1 is gone.
> (gdb) FAIL: gdb.base/nextoverexit.exp: next over exit (the program exited)
> 
> Can others confirm this/is this a known issue?

Hmm, that message is new, but we shouldn't be seeing it for
internal breakpoints...  That'll be my fault.  I'll take a look.

-- 
Pedro Alves

Re: [COMMIT PATCH] [Hurd/gnu-nat] Fix old "signal-thread" command regression.

[Thomas Schwinge]

Hi Pedro!

On Wed, 18 Sep 2013 13:01:39 +0100, Pedro Alves  wrote:
> By inspection, I noticed that when I made the gnu-nat use
> ptid(pid,0,tid) to represent a thread, instead of using ptid(tid,0,0),
> in , I
> introduced a bug.
> 
> The change was: [...]

> So before, [...]
> 
> The right fix is to compare the whole ptid to minus_one_ptid, of
> course.
> 
> Completely untested, but I think it's obvious enough, so I went ahead
> and put it in.

Thanks!  Now confirmed the issue as well as the fix.


As I found some months ago, Hurd GDB's signal-thread detection is broken
anyway, but despite that, GDB does work -- will have to look into that.


Grüße,
 Thomas


pgpoayEKtgLaG.pgp
Description: PGP signature

Re: [PATCH 10/16] hurd: add fsys_get_children

[Justus Winter]

Quoting David Michael (2013-09-17 18:43:24)
> Hi,
> 
> On Tue, Jul 30, 2013 at 5:59 AM, Justus Winter
> <4win...@informatik.uni-hamburg.de> wrote:
> > * hurd/fsys.defs: Add fsys_get_children.
> > * hurd/fsys_reply.defs: Add fsys_get_children.
> 
> While trying to build the latest changes, this seems to result in a
> new compile failure.  The file libdiskfs/boot-start.c includes both
>  and "fsys_reply_U.h" which contain conflicting
> definitions of fsys_get_children.  It builds by choosing one or the
> other.  However, I haven't dug into this to tell what else may be
> affected, so I thought I'd better ask for any suggestions on how to
> proceed.

Oh, that's my fault indeed. I'll send a patch series with some fixups
shortly...

Sorry for the inconvenience,
Justus

[PATCH 3/5] sutils: set up /dev/null using /bin/nullpriv in MAKEDEV.sh

[Justus Winter]

This patch makes MAKEDEV.sh use the /bin/nullpriv wrapper so that the
storeio translator serving /dev/null is started without any unix
privileges.

* sutils/MAKEDEV.sh (mkdev): Use /bin/nullpriv for /dev/null.
---
 sutils/MAKEDEV.sh |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sutils/MAKEDEV.sh b/sutils/MAKEDEV.sh
index 1d164c7..0a8f514 100644
--- a/sutils/MAKEDEV.sh
+++ b/sutils/MAKEDEV.sh
@@ -116,7 +116,7 @@ mkdev() {
   full)
st $I root 666 /hurd/null --full;;
   zero)
-   st $I root 666 /hurd/storeio -Tzero;;
+   st $I root 666 /bin/nullauth -- /hurd/storeio -Tzero;;
   tty)
st $I root 666 /hurd/magic tty;;
   fd)
-- 
1.7.10.4

[PATCH 2/5] daemons: make sure /proc is properly set up

[Justus Winter]

This patch makes runsystem.sh check whether /proc is set up and does
so using settrans -c if it is not.

* daemons/runsystem.sh: Make sure /proc is set up.
---
 daemons/runsystem.sh |8 
 1 file changed, 8 insertions(+)

diff --git a/daemons/runsystem.sh b/daemons/runsystem.sh
index f4f2771..5a24674 100644
--- a/daemons/runsystem.sh
+++ b/daemons/runsystem.sh
@@ -68,6 +68,14 @@ if ! test -e /servers/socket/1 ; then
   fi
 fi
 
+# See whether procfs is set up
+if ! test -e /proc/cmdline ; then
+  # The root filesystem might be read-only at this point.
+  if fsysopts / --update --writable ; then
+settrans -c /proc /hurd/procfs --compatible
+  fi
+fi
+
 # We expect to be started by console-run, which gives us no arguments and
 # puts FALLBACK_CONSOLE=file-name in the environment if our console is
 # other than a normal /dev/console.
-- 
1.7.10.4

[PATCH 1/5] daemons: make sure / is writable before setting up pflocal

[Justus Winter]

runsystem.sh checks whether /servers/socket/1 exists and creates it
using settrans -c if it does not. But at this point in the boot the
root filesystem is normally not writable. This patch fixes this.

* daemons/runsystem.sh: Make sure / is writable before attempting to
  set up pflocal.
---
 daemons/runsystem.sh |   15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/daemons/runsystem.sh b/daemons/runsystem.sh
index 4b9334e..f4f2771 100644
--- a/daemons/runsystem.sh
+++ b/daemons/runsystem.sh
@@ -55,10 +55,17 @@ function singleuser ()
 }
 
 
-# See whether pflocal is setup already, and do so if not (install case)
-
-if ! test -e /servers/socket/1 && which settrans >/dev/null ; then
-  settrans -c /servers/socket/1 /hurd/pflocal
+# See whether pflocal is set up already, and do so if not (install case)
+#
+# Normally this should be the case, but we better make sure since
+# without the pflocal server, pipe(2) does not work.
+if ! test -e /servers/socket/1 ; then
+  # The root filesystem should be read-only at this point.
+  if fsysopts / --update --writable ; then
+settrans -c /servers/socket/1 /hurd/pflocal
+  else
+singleuser "Failed to create /servers/socket/1."
+  fi
 fi
 
 # We expect to be started by console-run, which gives us no arguments and
-- 
1.7.10.4

[PATCH 5/5] hurd: add _reply suffix to the routines in fsys_reply.defs

[Justus Winter]

* hurd/fsys_reply.defs: Add _reply suffix.
---
 hurd/fsys_reply.defs |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hurd/fsys_reply.defs b/hurd/fsys_reply.defs
index 2f5b035..89fb3a4 100644
--- a/hurd/fsys_reply.defs
+++ b/hurd/fsys_reply.defs
@@ -77,12 +77,12 @@ simpleroutine fsys_get_options_reply (
RETURN_CODE_ARG;
options: data_t);
 
-simpleroutine fsys_get_children (
+simpleroutine fsys_get_children_reply (
server: fsys_t;
RETURN_CODE_ARG;
children: data_t);
 
-simpleroutine fsys_get_source (
+simpleroutine fsys_get_source_reply (
server: fsys_t;
RETURN_CODE_ARG;
source: string_t);
-- 
1.7.10.4

[PATCH 4/5] hurd: add _reply suffix to the routines in process_reply.defs

[Justus Winter]

* hurd/process_reply.defs: Add _reply suffix.
---
 hurd/process_reply.defs |   42 +-
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/hurd/process_reply.defs b/hurd/process_reply.defs
index 66a7551..ed46d55 100644
--- a/hurd/process_reply.defs
+++ b/hurd/process_reply.defs
@@ -70,107 +70,107 @@ skip; /* proc_mark_exec */
 skip; /* proc_mark_traced */
 skip; /* proc_mod_stopchild */
 
-simpleroutine proc_pid2task (
+simpleroutine proc_pid2task_reply (
reply_port: reply_port_t;
RETURN_CODE_ARG;
task: task_t);
 
-simpleroutine proc_task2pid (
+simpleroutine proc_task2pid_reply (
reply_port: reply_port_t;
RETURN_CODE_ARG;
pid: pid_t);
 
-simpleroutine proc_task2proc (
+simpleroutine proc_task2proc_reply (
reply_port: reply_port_t;
RETURN_CODE_ARG;
proc: mach_port_make_send_t);
 
-simpleroutine proc_proc2task (
+simpleroutine proc_proc2task_reply (
reply_port: reply_port_t;
RETURN_CODE_ARG;
task: task_t);
 
-simpleroutine proc_pid2proc (
+simpleroutine proc_pid2proc_reply (
reply_port: reply_port_t;
RETURN_CODE_ARG;
proc: mach_port_make_send_t);
 
-simpleroutine proc_getprocinfo (
+simpleroutine proc_getprocinfo_reply (
reply_port: reply_port_t;
RETURN_CODE_ARG;
flags: int;
procinfo: procinfo_t, dealloc;
threadwaits: data_t, dealloc);
 
-simpleroutine proc_getprocargs (
+simpleroutine proc_getprocargs_reply (
reply_port: reply_port_t;
RETURN_CODE_ARG;
procargs: data_t, dealloc);
 
-simpleroutine proc_getprocenv (
+simpleroutine proc_getprocenv_reply (
reply_port: reply_port_t;
RETURN_CODE_ARG;
procenv: data_t, dealloc);
 
 skip; /* proc_make_login_coll */
 
-simpleroutine proc_getloginid (
+simpleroutine proc_getloginid_reply (
reply_port: reply_port_t;
RETURN_CODE_ARG;
login_id: pid_t);
 
-simpleroutine proc_getloginpids (
+simpleroutine proc_getloginpids_reply (
reply_port: reply_port_t;
RETURN_CODE_ARG;
pids: pidarray_t, dealloc);
 
 skip; /* proc_setlogin */
 
-simpleroutine proc_getlogin (
+simpleroutine proc_getlogin_reply (
reply_port: reply_port_t;
RETURN_CODE_ARG;
logname: string_t);
 
 skip; /* proc_setsid */
 
-simpleroutine proc_getsid (
+simpleroutine proc_getsid_reply (
reply_port: reply_port_t;
RETURN_CODE_ARG;
sid: pid_t);
 
-simpleroutine proc_getsessionpgids (
+simpleroutine proc_getsessionpgids_reply (
reply_port: reply_port_t;
RETURN_CODE_ARG;
pgidset: pidarray_t, dealloc);
 
-simpleroutine proc_getsessionpids (
+simpleroutine proc_getsessionpids_reply (
reply_port: reply_port_t;
RETURN_CODE_ARG;
pidset: pidarray_t, dealloc);
 
-simpleroutine proc_getsidport (
+simpleroutine proc_getsidport_reply (
reply_port: reply_port_t;
RETURN_CODE_ARG;
sessport: mach_port_send_t);
 
 skip; /* proc_setpgrp */
 
-simpleroutine proc_getpgrp (
+simpleroutine proc_getpgrp_reply (
reply_port: reply_port_t;
RETURN_CODE_ARG;
pgrp: pid_t);
 
-simpleroutine proc_getpgrppids (
+simpleroutine proc_getpgrppids_reply (
reply_port: reply_port_t;
RETURN_CODE_ARG;
pidset: pidarray_t, dealloc);
 
-simpleroutine proc_get_tty (
+simpleroutine proc_get_tty_reply (
reply_port: reply_port_t;
RETURN_CODE_ARG;
tty: mach_port_send_t);
 
-simpleroutine proc_getnports (
+simpleroutine proc_getnports_reply (
reply_port: reply_port_t;
RETURN_CODE_ARG;
nports: mach_msg_type_number_t);
@@ -180,14 +180,14 @@ simpleroutine proc_getnports (
 skip;  /* Reserved for proc_set_init_task */
 skip; /* proc_mark_important */
 
-simpleroutine proc_is_important (
+simpleroutine proc_is_important_reply (
reply_port: reply_port_t;
RETURN_CODE_ARG;
essential: boolean_t);
 
 skip; /* proc_set_code */
 
-simpleroutine proc_get_code (
+simpleroutine proc_get_code_reply (
reply_port: reply_port_t;
RETURN_CODE_ARG;
start_code: vm_address_t;
-- 
1.7.10.4

Re: [PATCH 2/5] daemons: make sure /proc is properly set up

[Ludovic Courtès]

Justus Winter <4win...@informatik.uni-hamburg.de> skribis:

> This patch makes runsystem.sh check whether /proc is set up and does
> so using settrans -c if it is not.

I think this should be a Debian patch rather, because while /proc is a
useful Linux compatibility feature, it’s not a mandatory part of the Hurd.

WDYT?

Ludo’.

Re: [PATCH 2/5] daemons: make sure /proc is properly set up

[Justus Winter]

Quoting Ludovic =?utf-8?Q?Court=C3=A8s?= (2013-09-19 12:19:00)
> Justus Winter <4win...@informatik.uni-hamburg.de> skribis:
> 
> > This patch makes runsystem.sh check whether /proc is set up and does
> > so using settrans -c if it is not.
> 
> I think this should be a Debian patch rather, because while /proc is a
> useful Linux compatibility feature, it’s not a mandatory part of the Hurd.

Ah yes, of course. I keep getting those mixed up in my head ;)

Then again, I always wondered why the procfs lives outside the Hurd
source. Yes, Linux has /proc, but so do many other Unixes and - if
memory serves right - /proc is a gift from plan9, no?

And the Hurd uses the filesystem as namespace for server lookups, that
seems to follow closely the everything-is-a-file philosophy right? And
if everything is a file, processes should be as well, hence /proc.

Justus

Re: [PATCH 2/5] daemons: make sure /proc is properly set up

[Ludovic Courtès]

Justus Winter <4win...@informatik.uni-hamburg.de> skribis:

> Quoting Ludovic =?utf-8?Q?Court=C3=A8s?= (2013-09-19 12:19:00)
>> Justus Winter <4win...@informatik.uni-hamburg.de> skribis:
>> 
>> > This patch makes runsystem.sh check whether /proc is set up and does
>> > so using settrans -c if it is not.
>> 
>> I think this should be a Debian patch rather, because while /proc is a
>> useful Linux compatibility feature, it’s not a mandatory part of the Hurd.
>
> Ah yes, of course. I keep getting those mixed up in my head ;)
>
> Then again, I always wondered why the procfs lives outside the Hurd
> source. Yes, Linux has /proc, but so do many other Unixes and - if
> memory serves right - /proc is a gift from plan9, no?
>
> And the Hurd uses the filesystem as namespace for server lookups, that
> seems to follow closely the everything-is-a-file philosophy right? And
> if everything is a file, processes should be as well, hence /proc.

Passing data around as text is what Plan 9 does, whereas the Hurd uses
dedicated interfaces and RPCs.

RPCs are a richer way to exchange information than plain text since
their arguments and return values are typed; they can also be easily
interposed on, etc.

The information that Linux-style /proc provides can be obtained through
appropriate RPCs to the proc server, to the msg interface of POSIX
processes, etc.

But you already know all this.  :-)

It suppose Debian uses tools coming from Linux that expect /proc to be
present (such as ‘procps’), in which case it makes sense for Debian to
have /proc mounted early.

Ludo’.

Re: [RFC] GDB Hurd Fixes

[David Michael]

Hi,

(Copying gdb-patches this time.)

Here is an updated patch to successfully build GDB after today's
Hurd/mig changes.

The awk script changes handle the "auto" keyword being dropped from
mig output, and that an "#if TypeCheck" line appears before
arg_check_name is defined in some new functions.

The gnu-nat.c changes define functions for the new process_reply.defs entries.

I'd appreciate any feedback or suggestions for getting GDB building on
current Hurd again.

Thanks.

David


--- gdb/reply_mig_hack.awk2013-01-01 01:32:50.0 -0500
+++ gdb/reply_mig_hack.awk2013-01-01 01:32:50.0 -0500
@@ -85,13 +85,20 @@ parse_phase == 5 && /^[ \t]*(auto|static
   print; next;
 }

+parse_phase == 5 && /^[ \t]*const mach_msg_type_t/ {
+  # The type check structure for an argument.
+  arg_check_name[num_checks] = $3;
+  num_checks++;
+  print; next;
+}
+
 parse_phase == 5 && /^[ \t]*mig_external kern_return_t/ {
   # The declaration of the user server function for this rpc.
   user_function_name = $3;
   print; next;
 }

-parse_phase == 5 && /^#if[ \t]TypeCheck/ {
+parse_phase == 5 && /^#if[ \t]TypeCheck/ && num_checks > 0 {
   # The first args type checking statement; we need to insert our chunk of
   # code that bypasses all the type checks if this is an error return, after
   # which we're done until we get to the next function.  Handily, the size
--- gdb/gnu-nat.c2013-01-01 01:32:44.0 -0500
+++ gdb/gnu-nat.c2013-01-01 01:32:44.0 -0500
@@ -1902,6 +1902,142 @@ S_proc_getmsgport_reply (mach_port_t rep
   return ill_rpc ("S_proc_getmsgport_reply");
 }

+error_t
+S_proc_pid2task_reply (mach_port_t reply, error_t err, mach_port_t task)
+{
+  return ill_rpc ("S_proc_pid2task_reply");
+}
+
+error_t
+S_proc_task2pid_reply (mach_port_t reply, error_t err, pid_t pid)
+{
+  return ill_rpc ("S_proc_task2pid_reply");
+}
+
+error_t
+S_proc_task2proc_reply (mach_port_t reply, error_t err, mach_port_t proc)
+{
+  return ill_rpc ("S_proc_task2proc_reply");
+}
+
+error_t
+S_proc_proc2task_reply (mach_port_t reply, error_t err, mach_port_t task)
+{
+  return ill_rpc ("S_proc_proc2task_reply");
+}
+
+error_t
+S_proc_pid2proc_reply (mach_port_t reply, error_t err, mach_port_t proc)
+{
+  return ill_rpc ("S_proc_pid2proc_reply");
+}
+
+error_t
+S_proc_getprocinfo_reply (mach_port_t reply, error_t err, int flags,
+  procinfo_t procinfo, mach_msg_type_number_t piCnt,
+  data_t threadwaits, mach_msg_type_number_t twCnt)
+{
+  return ill_rpc ("S_proc_getprocinfo_reply");
+}
+
+error_t
+S_proc_getprocargs_reply (mach_port_t reply, error_t err,
+  data_t procargs, mach_msg_type_number_t procargsCnt)
+{
+  return ill_rpc ("S_proc_getprocargs_reply");
+}
+
+error_t
+S_proc_getprocenv_reply (mach_port_t reply, error_t err,
+ data_t procenv, mach_msg_type_number_t procenvCnt)
+{
+  return ill_rpc ("S_proc_getprocenv_reply");
+}
+
+error_t
+S_proc_getloginid_reply (mach_port_t reply, error_t err, pid_t login_id)
+{
+  return ill_rpc ("S_proc_getloginid_reply");
+}
+
+error_t
+S_proc_getloginpids_reply (mach_port_t reply, error_t err,
+   pidarray_t pids, mach_msg_type_number_t pidsCnt)
+{
+  return ill_rpc ("S_proc_getloginpids_reply");
+}
+
+error_t
+S_proc_getlogin_reply (mach_port_t reply, error_t err, string_t logname)
+{
+  return ill_rpc ("S_proc_getlogin_reply");
+}
+
+error_t
+S_proc_getsid_reply (mach_port_t reply, error_t err, pid_t sid)
+{
+  return ill_rpc ("S_proc_getsid_reply");
+}
+
+error_t
+S_proc_getsessionpgids_reply (mach_port_t reply, error_t err,
+  pidarray_t pgidset, mach_msg_type_number_t psCnt)
+{
+  return ill_rpc ("S_proc_getsessionpgids_reply");
+}
+
+error_t
+S_proc_getsessionpids_reply (mach_port_t reply, error_t err,
+ pidarray_t pidset, mach_msg_type_number_t psCnt)
+{
+  return ill_rpc ("S_proc_getsessionpids_reply");
+}
+
+error_t
+S_proc_getsidport_reply (mach_port_t reply, error_t err, mach_port_t sessport)
+{
+  return ill_rpc ("S_proc_getsidport_reply");
+}
+
+error_t
+S_proc_getpgrp_reply (mach_port_t reply, error_t err, pid_t pgrp)
+{
+  return ill_rpc ("S_proc_getpgrp_reply");
+}
+
+error_t
+S_proc_getpgrppids_reply (mach_port_t reply, error_t err,
+  pidarray_t pidset, mach_msg_type_number_t pidsetCnt)
+{
+  return ill_rpc ("S_proc_getpgrppids_reply");
+}
+
+error_t
+S_proc_get_tty_reply (mach_port_t reply, error_t err, mach_port_t tty)
+{
+  return ill_rpc ("S_proc_get_tty_reply");
+}
+
+error_t
+S_proc_getnports_reply (mach_port_t reply, error_t err,
+mach_msg_type_number_t nports)
+{
+  return ill_rpc ("S_proc_getnports_reply");
+}
+
+error_t
+S_proc_is_important_reply (mach_port_t reply, error_t err, boolean_t essential)
+{
+  return ill_rpc ("S_proc_is_important_reply");
+}
+
+error_t
+S_proc_get_code_reply (mach_port_t reply, error_t