Re: proc_task2proc prototype change

2017-05-07 Thread Samuel Thibault 
Justus Winter, on dim. 07 mai 2017 17:42:24 +0200, wrote:
> Can you paste the client code?

kern_return_t __proc_task2proc
(
process_t process,
mach_port_t task,
mach_port_t *proc,
mach_msg_type_name_t *procPoly
) {

...

*proc = OutP->proc;

*procPoly = OutP->procType.msgt_name;

return KERN_SUCCESS;
}



Samuel

Re: proc_task2proc prototype change

2017-05-07 Thread Justus Winter 
Samuel Thibault  writes:

> David Michael, on sam. 06 mai 2017 12:28:51 -0700, wrote:
>> The new generated functions all get an additional
>> "mach_msg_type_name_t *msgportPoly" parameter and none of the callers
>> were updated, so they all fail to compile with "too few arguments"
>> errors.
>
> Indeed, rebuilding glibc gives:
>
> hurdexec.c:72:29: error: too few arguments to function ‘__proc_task2proc’
>
> because client RPC stubs are built by glibc that went unnoticed.
>
> Do RPC-knowledgeable people know a way to have this change happen in the
> server only?  Perhaps just using a typedef which will not be the
> same in the server and the client?

Whoops.  That was me.  But tbh, since I only changed out parameters (and
obviously the *in* parameters of the async reply part), I don't see why
that should change the client stub (as I remarked in the commit
message).

What did I miss?  Can you paste the client code?  I still don't see why
the out parameter should possibly be polymorphic at the client side, and
cannot even imagine what the semantic could be...

Justus


signature.asc
Description: PGP signature

proc_task2proc prototype change

2017-05-07 Thread Samuel Thibault 
Hello,

Copy/pasting the whole story again, since it was hidden behind an
unrelated issue.

David Michael, on ven. 05 mai 2017 22:33:57 -0700, wrote:
> Side note:  I couldn't bootstrap cross-compilers with
> tschwinge/Roger_Whittaker since the last proc defs changes.  Is there
> a more current branch somewhere?

Samuel Thibault, on sam. 06 mai 2017 11:26:37 +0200, wrote:
> What issue do you get?

David Michael, on sam. 06 mai 2017 12:28:51 -0700, wrote:
> The new generated functions all get an additional
> "mach_msg_type_name_t *msgportPoly" parameter and none of the callers
> were updated, so they all fail to compile with "too few arguments"
> errors.

Indeed, rebuilding glibc gives:

hurdexec.c:72:29: error: too few arguments to function ‘__proc_task2proc’

because client RPC stubs are built by glibc that went unnoticed.

Do RPC-knowledgeable people know a way to have this change happen in the
server only?  Perhaps just using a typedef which will not be the
same in the server and the client?

Samuel

Re: [PATCH gnumach] Support GCC 7

2017-05-07 Thread Samuel Thibault 
David Michael, on sam. 06 mai 2017 12:13:01 -0700, wrote:
> * Makefile.am (clib_routines): Add __udivmoddi4.
> * linux/src/include/linux/compiler-gcc7.h: New file.

Applied, thanks!

Samuel