hurd: update RPC prototypes

hurd: update RPC prototypes

[Samuel Thibault]

Since hurd's baf7e5c ('hurd: Use polymorphic port types to return some
rights.'), some RPCs prototypes have changed, gdb needs the
corresponding update.

* gdb/gnu-nat.c (S_proc_getmsgport_reply, S_proc_task2proc_reply,
S_proc_pid2proc_reply): Add `mach_msg_type_name_t type' parameter.

diff --git a/gdb/gnu-nat.c b/gdb/gnu-nat.c
index d5e3841e68..402027866b 100644
--- a/gdb/gnu-nat.c
+++ b/gdb/gnu-nat.c
@@ -1874,17 +1876,19 @@ ILL_RPC (S_proc_setmsgport_reply,
 	 mach_port_t oldmsgport)
 ILL_RPC (S_proc_getmsgport_reply,
 	 mach_port_t reply_port, kern_return_t return_code,
-	 mach_port_t msgports)
+	 mach_port_t msgports, mach_msg_type_name_t type)
 ILL_RPC (S_proc_pid2task_reply,
 	 mach_port_t reply_port, kern_return_t return_code, mach_port_t task)
 ILL_RPC (S_proc_task2pid_reply,
 	 mach_port_t reply_port, kern_return_t return_code, pid_t pid)
 ILL_RPC (S_proc_task2proc_reply,
-	 mach_port_t reply_port, kern_return_t return_code, mach_port_t proc)
+	 mach_port_t reply_port, kern_return_t return_code,
+	 mach_port_t proc, mach_msg_type_name_t type)
 ILL_RPC (S_proc_proc2task_reply,
 	 mach_port_t reply_port, kern_return_t return_code, mach_port_t task)
 ILL_RPC (S_proc_pid2proc_reply,
-	 mach_port_t reply_port, kern_return_t return_code, mach_port_t proc)
+	 mach_port_t reply_port, kern_return_t return_code,
+	 mach_port_t proc, mach_msg_type_name_t type)
 ILL_RPC (S_proc_getprocinfo_reply,
 	 mach_port_t reply_port, kern_return_t return_code,
 	 int flags, procinfo_t procinfo, mach_msg_type_number_t procinfoCnt,

Re: hurd: update RPC prototypes

[Pedro Alves]

On 08/27/2017 07:41 PM, Samuel Thibault wrote:
> Since hurd's baf7e5c ('hurd: Use polymorphic port types to return some
> rights.'), some RPCs prototypes have changed, gdb needs the
> corresponding update.
> 
> * gdb/gnu-nat.c (S_proc_getmsgport_reply, S_proc_task2proc_reply,
> S_proc_pid2proc_reply): Add `mach_msg_type_name_t type' parameter.

Say someone downloads some prebuilt Debian Hurd image or some
such and wants to build newer gdb on that system.  I assume that that would be
broken with this change?  What's the policy regarding building ToT gdb on
non-ToT Hurd systems?  Is the intention to only ever support building
ToT gdb with ToT Hurd?

Thanks,
Pedro Alves

> 
> diff --git a/gdb/gnu-nat.c b/gdb/gnu-nat.c
> index d5e3841e68..402027866b 100644
> --- a/gdb/gnu-nat.c
> +++ b/gdb/gnu-nat.c
> @@ -1874,17 +1876,19 @@ ILL_RPC (S_proc_setmsgport_reply,
>  	 mach_port_t oldmsgport)
>  ILL_RPC (S_proc_getmsgport_reply,
>  	 mach_port_t reply_port, kern_return_t return_code,
> -	 mach_port_t msgports)
> +	 mach_port_t msgports, mach_msg_type_name_t type)
>  ILL_RPC (S_proc_pid2task_reply,
>  	 mach_port_t reply_port, kern_return_t return_code, mach_port_t task)
>  ILL_RPC (S_proc_task2pid_reply,
>  	 mach_port_t reply_port, kern_return_t return_code, pid_t pid)
>  ILL_RPC (S_proc_task2proc_reply,
> -	 mach_port_t reply_port, kern_return_t return_code, mach_port_t proc)
> +	 mach_port_t reply_port, kern_return_t return_code,
> +	 mach_port_t proc, mach_msg_type_name_t type)
>  ILL_RPC (S_proc_proc2task_reply,
>  	 mach_port_t reply_port, kern_return_t return_code, mach_port_t task)
>  ILL_RPC (S_proc_pid2proc_reply,
> -	 mach_port_t reply_port, kern_return_t return_code, mach_port_t proc)
> +	 mach_port_t reply_port, kern_return_t return_code,
> +	 mach_port_t proc, mach_msg_type_name_t type)
>  ILL_RPC (S_proc_getprocinfo_reply,
>  	 mach_port_t reply_port, kern_return_t return_code,
>  	 int flags, procinfo_t procinfo, mach_msg_type_number_t procinfoCnt,
> 

Re: hurd: update RPC prototypes

[Samuel Thibault]

Hello,

Pedro Alves, on lun. 04 sept. 2017 13:14:33 +0100, wrote:
> On 08/27/2017 07:41 PM, Samuel Thibault wrote:
> > Since hurd's baf7e5c ('hurd: Use polymorphic port types to return some
> > rights.'), some RPCs prototypes have changed, gdb needs the
> > corresponding update.
> > 
> > * gdb/gnu-nat.c (S_proc_getmsgport_reply, S_proc_task2proc_reply,
> > S_proc_pid2proc_reply): Add `mach_msg_type_name_t type' parameter.
> 
> Say someone downloads some prebuilt Debian Hurd image or some
> such and wants to build newer gdb on that system.  I assume that that would be
> broken with this change?

Yes.

> What's the policy regarding building ToT gdb on non-ToT Hurd systems?
> Is the intention to only ever support building ToT gdb with ToT Hurd?

ATM we don't really support backward compatibility for mixtures of
versions.

Samuel

Re: hurd: update RPC prototypes

[Pedro Alves]

On 09/06/2017 11:11 PM, Samuel Thibault wrote:

> Pedro Alves, on lun. 04 sept. 2017 13:14:33 +0100, wrote:
>> On 08/27/2017 07:41 PM, Samuel Thibault wrote:
>>> Since hurd's baf7e5c ('hurd: Use polymorphic port types to return some
>>> rights.'), some RPCs prototypes have changed, gdb needs the
>>> corresponding update.
>>>
>>> * gdb/gnu-nat.c (S_proc_getmsgport_reply, S_proc_task2proc_reply,
>>> S_proc_pid2proc_reply): Add `mach_msg_type_name_t type' parameter.
>>
>> Say someone downloads some prebuilt Debian Hurd image or some
>> such and wants to build newer gdb on that system.  I assume that that would be
>> broken with this change?
> 
> Yes.
> 
>> What's the policy regarding building ToT gdb on non-ToT Hurd systems?
>> Is the intention to only ever support building ToT gdb with ToT Hurd?
> 
> ATM we don't really support backward compatibility for mixtures of
> versions.

OK, seems to me that raises bar of entry to gdb/hurd hacking,
but really up to you guys.  A few years back, when I did some
across-all-gdb-targets changes, I used the prebuilt Debian
Hurd qemu image to do&test the corresponding Hurd changes.  Guess
I may have been lucky then to not hit some version skew.

Thanks,
Pedro Alves

Re: hurd: update RPC prototypes

[Samuel Thibault]

Ping?

Samuel Thibault, le dim. 27 août 2017 20:41:02 +0200, a ecrit:
> Since hurd's baf7e5c ('hurd: Use polymorphic port types to return some
> rights.'), some RPCs prototypes have changed, gdb needs the
> corresponding update.
> 
> * gdb/gnu-nat.c (S_proc_getmsgport_reply, S_proc_task2proc_reply,
> S_proc_pid2proc_reply): Add `mach_msg_type_name_t type' parameter.
> 
> diff --git a/gdb/gnu-nat.c b/gdb/gnu-nat.c
> index d5e3841e68..402027866b 100644
> --- a/gdb/gnu-nat.c
> +++ b/gdb/gnu-nat.c
> @@ -1874,17 +1876,19 @@ ILL_RPC (S_proc_setmsgport_reply,
>  	 mach_port_t oldmsgport)
>  ILL_RPC (S_proc_getmsgport_reply,
>  	 mach_port_t reply_port, kern_return_t return_code,
> -	 mach_port_t msgports)
> +	 mach_port_t msgports, mach_msg_type_name_t type)
>  ILL_RPC (S_proc_pid2task_reply,
>  	 mach_port_t reply_port, kern_return_t return_code, mach_port_t task)
>  ILL_RPC (S_proc_task2pid_reply,
>  	 mach_port_t reply_port, kern_return_t return_code, pid_t pid)
>  ILL_RPC (S_proc_task2proc_reply,
> -	 mach_port_t reply_port, kern_return_t return_code, mach_port_t proc)
> +	 mach_port_t reply_port, kern_return_t return_code,
> +	 mach_port_t proc, mach_msg_type_name_t type)
>  ILL_RPC (S_proc_proc2task_reply,
>  	 mach_port_t reply_port, kern_return_t return_code, mach_port_t task)
>  ILL_RPC (S_proc_pid2proc_reply,
> -	 mach_port_t reply_port, kern_return_t return_code, mach_port_t proc)
> +	 mach_port_t reply_port, kern_return_t return_code,
> +	 mach_port_t proc, mach_msg_type_name_t type)
>  ILL_RPC (S_proc_getprocinfo_reply,
>  	 mach_port_t reply_port, kern_return_t return_code,
>  	 int flags, procinfo_t procinfo, mach_msg_type_number_t procinfoCnt,

[gdb, hurd] Adjust to Hurd "proc" interface changes (was: proc_task2proc prototype change)

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 1525 bytes --]

Hi!

On Tue, 06 Jun 2017 08:49:16 +0200, Justus Winter <justus@gnupg.org> wrote:
> David Michael <fedora.dm0@gmail.com> writes:
> > On Mon, Jun 5, 2017 at 7:40 AM, Justus Winter <justus@gnupg.org> wrote:
> >> [...]

> > The reply
> > functions still have mach_port_poly_t, though, and they are used by
> > GDB.  Is that correct?
> 
> Oh wow, a server for the reply part of a protocol.  Odd.  Well, I
> decided not to revert the change to the reply part so that it is
> consistent with how the reply of a server for the full protocol works.
> 
> > It will require something like the following to get GDB to compile due
> > to the changed generated definitions.
> > [...]
> >  ILL_RPC (S_proc_getmsgport_reply,
> >       mach_port_t reply_port, kern_return_t return_code,
> > -     mach_port_t msgports)
> > +     mach_port_t msgports, mach_msg_type_name_t msgportsPoly)

ACK, thanks; I pushed to GDB master the attached commit
8071c5ce78245eff43f9977a7c3ff8328f7486da '[gdb, hurd] Adjust to Hurd
"proc" interface changes'.

> Well, seeing that ILL_RPC is for unused procedures, it would be much
> easier to use MIGs "new" way of creating default server stubs that
> return a fixed value.  This can be done by #defining MIG_EOPNOTSUPP to
> some value while compiling the MIG-generated server stub.  Being a
> simpleroutine it doesn't really matter to what value, but EOPNOTSUPP
> seems to be a better choice than ILL_RPC's 0.

Thanks, we shall look into that later.


Grüße
 Thomas



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gdb-hurd-Adjust-to-Hurd-proc-interface-changes.patch --]
[-- Type: text/x-diff, Size: 3254 bytes --]

From 8071c5ce78245eff43f9977a7c3ff8328f7486da Mon Sep 17 00:00:00 2001
From: David Michael <fedora.dm0@gmail.com>
Date: Mon, 5 Jun 2017 17:35:11 -0700
Subject: [PATCH] [gdb, hurd] Adjust to Hurd "proc" interface changes

Hurd's commit baf7e5c8ce176aead15c2559952d8bdf0da41ffd "hurd: Use polymorphic
port types to return some rights" causes in the GDB build:

    /usr/bin/ld: process_reply_S.o: in function `_Xproc_pid2proc_reply':
    [...]/gdb/process_reply_S.c:754: undefined reference to `S_proc_pid2proc_reply'
    /usr/bin/ld: [...]/gdb/process_reply_S.c:730: undefined reference to `S_proc_pid2proc_reply'
    /usr/bin/ld: process_reply_S.o: in function `_Xproc_task2proc_reply':
    [...]/gdb/process_reply_S.c:589: undefined reference to `S_proc_task2proc_reply'
    /usr/bin/ld: [...]/gdb/process_reply_S.c:565: undefined reference to `S_proc_task2proc_reply'
    /usr/bin/ld: process_reply_S.o: in function `_Xproc_getmsgport_reply':
    [...]/gdb/process_reply_S.c:204: undefined reference to `S_proc_getmsgport_reply'
    /usr/bin/ld: [...]/gdb/process_reply_S.c:180: undefined reference to `S_proc_getmsgport_reply'
    collect2: error: ld returned 1 exit status

	gdb/
	* gnu-nat.c (S_proc_getmsgport_reply, S_proc_task2proc_reply)
	(S_proc_pid2proc_reply): Adjust to Hurd "proc" interface changes.
---
 gdb/ChangeLog | 7 +++++++
 gdb/gnu-nat.c | 8 +++++---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index e427dda8a3..f2bbd77558 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,10 @@
+2019-02-14  David Michael  <fedora.dm0@gmail.com>
+	    Samuel Thibault  <samuel.thibault@gnu.org>
+	    Thomas Schwinge  <thomas@codesourcery.com>
+
+	* gnu-nat.c (S_proc_getmsgport_reply, S_proc_task2proc_reply)
+	(S_proc_pid2proc_reply): Adjust to Hurd "proc" interface changes.
+
 2019-02-14  Thomas Schwinge  <thomas@codesourcery.com>
 
 	* gnu-nat.c (gnu_write_inferior, parse_int_arg, _parse_bool_arg)
diff --git a/gdb/gnu-nat.c b/gdb/gnu-nat.c
index 395b456ad7..53f23068a4 100644
--- a/gdb/gnu-nat.c
+++ b/gdb/gnu-nat.c
@@ -1880,17 +1880,19 @@ ILL_RPC (S_proc_setmsgport_reply,
 	 mach_port_t oldmsgport)
 ILL_RPC (S_proc_getmsgport_reply,
 	 mach_port_t reply_port, kern_return_t return_code,
-	 mach_port_t msgports)
+	 mach_port_t msgports, mach_msg_type_name_t msgportsPoly)
 ILL_RPC (S_proc_pid2task_reply,
 	 mach_port_t reply_port, kern_return_t return_code, mach_port_t task)
 ILL_RPC (S_proc_task2pid_reply,
 	 mach_port_t reply_port, kern_return_t return_code, pid_t pid)
 ILL_RPC (S_proc_task2proc_reply,
-	 mach_port_t reply_port, kern_return_t return_code, mach_port_t proc)
+	 mach_port_t reply_port, kern_return_t return_code,
+	 mach_port_t proc, mach_msg_type_name_t procPoly)
 ILL_RPC (S_proc_proc2task_reply,
 	 mach_port_t reply_port, kern_return_t return_code, mach_port_t task)
 ILL_RPC (S_proc_pid2proc_reply,
-	 mach_port_t reply_port, kern_return_t return_code, mach_port_t proc)
+	 mach_port_t reply_port, kern_return_t return_code,
+	 mach_port_t proc, mach_msg_type_name_t procPoly)
 ILL_RPC (S_proc_getprocinfo_reply,
 	 mach_port_t reply_port, kern_return_t return_code,
 	 int flags, procinfo_t procinfo, mach_msg_type_number_t procinfoCnt,
-- 
2.19.2