Re: proc_task2proc prototype change

[David Michael]

On Mon, Jun 5, 2017 at 7:40 AM, Justus Winter <justus@gnupg.org> wrote:
> Samuel Thibault <samuel.thibault@gnu.org> writes:
>
>> Hello,
>>
>> Justus Winter, on mar. 09 mai 2017 10:25:31 +0200, wrote:
>>> It is possible to do so using either some preprocessor trickery,
>>> or some other means of transformation (awk) on the protocol
>>> specification, or by manually rewriting and committing a specialized rpc
>>> definition.  Every one of these techniques is used in the Hurd, and I
>>> despise them all ;)
>>>
>>> Maybe we can fix MIG so that we can get server-side-polymorphic right
>>> parameters.
>>
>> Well, at least we need some solution for now, otherwise we get stuck :)
>>
>> AIUI, the least-ugly solution is to define a new type, which in the
>> server is defined to mach_port_poly_t and in the client is defined to
>> mach_port_t?
>
> As usual, the gods were way ahead of us, and introduced a way to specify
> a different type for the client and server side, and there is even
> already exactly the type that we need.  Quoting from the fine "Mach 3
> Server Writers Guide":
>
>> The other major use of transmission type changes is to specify a
>> parameter (most likely a port type) that is polymorphic on the
>> sender’s side (user side for in parameters, server side for out
>> parameters, both for inout parameters) but of a known type on the
>> receiver’s side. That is, the sender will specify a port and a port
>> type, but the result of sending this port will be to generate a known
>> port type. The following built-in MIG types have such a specification:
>>
>> [1]    type MACH_MSG_TYPE_PORT_RECEIVE =   -1 | 16;
>> [2]    type MACH_MSG_TYPE_PORT_SEND =      -1 | 17;
>> [3]    type MACH_MSG_TYPE_PORT_SEND_ONCE = -1 | 18;
>
> With the corresponding Mach type mach_port_send_t.  I committed a fix.

Thanks, I can confirm that fixed bootstrapping compilers.  The reply
functions still have mach_port_poly_t, though, and they are used by
GDB.  Is that correct?  It will require something like the following
to get GDB to compile due to the changed generated definitions.

Thanks.

David


--- gdb/gnu-nat.c
+++ gdb/gnu-nat.c
@@ -1864,17 +1864,19 @@
      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,