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

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

[Joe Simmons-Talbott]

Hi,

I'm investigating a build failure using build-many-glibcs.py for
i686-gnu.  There seems to be a mismatch between the declaration of
_hurdsig_fault_catch_exception_raise in hurd/hurdfault.c and the
generated header hurd/faultexc_server.h.  I can't figure out how the
header is being generated.

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.

Thanks,
Joe

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

[Carlos O'Donell]

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.

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

[Carlos O'Donell]

On 6/23/23 08:07, Joe Simmons-Talbott wrote:
> This is likely the case as it has been a while since I ran
> build-many-glibcs.py ./ collect.  Which leads me to the question; How
> do I keep my build-many-glibcs directory properly updated?  It seems
> that I should, every so often, remove the directory and re-run the
> collect, host-libraries, and compilers steps to get the latest
> changes.

There is no way to track cross-project dependencies today.

You just have to know that when a cross-project change occurs that you'll need to
checkout your sources again to get the latest version, particularly where that
source uses the main development branch.

We would have to add meta-data to the gnumach checkout information in bmg to track
which version of glibc works with that version of gnumach etc., but in practice
as a developer you just may need to checkout the latest in-flight version to get
things to work as we make cross-project changes.

It is possible to do better though, glibc's configure could have detected out of
date gnumach headers... but that's additional work that Sergey may not want to do
for an unreleased transient change between two projects.

In summary:

- When dealing with released version of projects we should use configure checks
  to detect header versions and issue diagnostics.

- When dealing with unreleased versions, this is just part of the developer
  requirements to stay up to date with the checkout of the latest cross-project
  dependencies.

-- 
Cheers,
Carlos.