hurd: update RPC prototypes
Commit Message
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.
Comments
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,
>
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
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
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,
@@ -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,