Re: build-many-glibcs.py build failure for i686-gnu

[Carlos O'Donell <carlos@redhat.com>]

On 6/23/23 07:59, Sergey Bugaev wrote:
> Hello,

I accidentally moved this off of libc-help (because of header from: rewriting).

> On Fri, Jun 23, 2023 at 2:25 PM Carlos O'Donell <carlos@redhat.com> wrote:
>> mach/exc.defs:
>>  41 routine         exception_raise(
>>  42                         exception_port  : mach_port_t;
>>  43                         thread          : mach_port_t;
>>  44                         task            : mach_port_t;
>>  45                         exception       : integer_t;
>>  46                         code            : integer_t;
>>  47                         subcode         : rpc_long_integer_t);
>>
>> The mistake here is that 'long_integer_t' in glibc is *always* a 'long int'
>>
>> While in gnumach 'rpc_long_integer_t' is not.
> 
> Yes, but that's the point of the rpc_* types: with x86_64 gnumach
> running i386 userland (USER32), rpc_long_integer_t will be 32-bit in
> userland and 64-bit in gnumach, and MIG magic will take care of
> converting between the two.
> 
> When building userland, rpc_long_integer_t is just always typdefed to
> long_integer_t, see gnumach:i386/include/mach/i386/vm_types.h:
> 
> #if defined(MACH_KERNEL) && defined(USER32)
> <snip>
> #else /* MACH_KERNEL */
> <snip>
> typedef long_natural_t rpc_long_natural_t;
> typedef long_integer_t rpc_long_integer_t;
> 
> #define convert_long_integer_to_user null_conversion
> #define convert_long_integer_from_user null_conversion
> #endif /* MACH_KERNEL */
> 
>> Sergey,
>>
>> Any thoughts on which is the right type?
>>
>> This currently blocks clean runs of build-many-glibcs.sh since it broke the
>> i686 hurd build.
> 
> rpc_long_integer_t should be the right type. And i686-gnu surely
> builds for me, so something else must be wrong. Perhaps the build
> machine has the old gnumach headers?
> 
>> I suspect d8ee5d614bc485f6d1752dfa0d60524b20945a56 which changed the type
>> caused the regression.
> 
> It is unfortunate that I had to alter the API, yes :(
> 
> But I couldn't think of a better way without altering the API even
> further (adding a separate RPC), and given the ABI on i686 stayed the
> same, this seemed like the best way forward. And I most definitely
> have tested that the i686-gnu build of glibc still works when making
> the change.
> 
>>> The error I'm seeing is:
>>>
>>> hurdfault.c:39:1: error: conflicting types for <E2><80><98>_hurdsig_fault_catch_exception_raise<E2><80><99>; have <E2>
>>> <80><98>kern_return_t(mach_port_t,  thread_t,  task_t,  integer_t,  integer_t,  long_integer_t)<E2><80><99> {aka <E2>
>>> <80><98>int(unsigned int,  unsigned int,  unsigned int,  int,  int,  long int)<E2><80><99>}
>>>    39 | _hurdsig_fault_catch_exception_raise (mach_port_t port,
>>>       | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> In file included from hurdfault.c:27:
>>> /home/josepht/build-many-glibcs/build/glibcs/i686-gnu/glibc/hurd/faultexc_server.h:19:15: note: previous declaration o
>>> f <E2><80><98>_hurdsig_fault_catch_exception_raise<E2><80><99> with type <E2><80><98>kern_return_t(mach_port_t,  mach_
>>> port_t,  mach_port_t,  integer_t,  integer_t,  integer_t)<E2><80><99> {aka <E2><80><98>int(unsigned int,  unsigned int
>>> ,  unsigned int,  int,  int,  int)<E2><80><99>}
>>>    19 | kern_return_t _hurdsig_fault_catch_exception_raise
>>>       |               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> make[3]: *** [../o-iterator.mk:9: /home/josepht/build-many-glibcs/build/glibcs/i686-gnu/glibc/hurd/hurdfault.o] Error
>>> 1
>>>
>>> Thanks for any insights.
> 
> My hurd/faultexc_server.h here (generated from gnumach MIG defs file,
> as Carlos says) has "rpc_long_integer_t subcode". Are you sure you
> have gnumach with the change? 4096bd9d9cbdbac9b1bfce99a393295f63a88cc5
> "Make exception subcode a long" is the relevant commit.
> 
> If you do have the new gnumach headers, maybe the glibc buildsystem
> fails to track the dependency of hurd/faultexc_server.h on
> mach/exc.defs? If so, removing hurd/faultexc* (or doing a clean build)
> should help.

That's exactly what we needed to know. It's likely Joe needs to checkout again.

-- 
Cheers,
Carlos.