From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id E21BF3858291 for ; Fri, 23 Jun 2023 12:26:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E21BF3858291 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1687523160; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=U+v46SF5AJX4WxRtsprh5mGf5IFor4V0vYtAY0BivbA=; b=BJjlKZcbPLruzXk7KPM+iVvIvfbszHviot5IvemgMuTGUH6Z/sibs3MuYhIF4HO+KrofIG YXIn9EGBtQd4XJqgqD654C+hARK73N3bzn0v1qF5I+eWLeqNj9TmFPNeU496bRle6z1osC RGUeAeRMGhRAiR4NMYQ0Y+74KP8hSIo= Received: from mail-oi1-f200.google.com (mail-oi1-f200.google.com [209.85.167.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-482-1gaE56CvPr6ob1wcgArrtQ-1; Fri, 23 Jun 2023 08:25:59 -0400 X-MC-Unique: 1gaE56CvPr6ob1wcgArrtQ-1 Received: by mail-oi1-f200.google.com with SMTP id 5614622812f47-39ecef7a101so461241b6e.2 for ; Fri, 23 Jun 2023 05:25:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687523158; x=1690115158; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=U+v46SF5AJX4WxRtsprh5mGf5IFor4V0vYtAY0BivbA=; b=a+Y87ZlwXVbfd90OBWPhuRrEx3LNao4ujecTD0/mcCPklSpEj6mPtHOxdazG/OPbd/ 9hEE1/Sj3hebTKHwe7TPXbdLsWIK759Y0GoQ4aZP5Yhi5+J7cgvqX7/hVGvlaLQXaTGb /4W8D7UxOzCDBQLkIcfpzhMEa7zg+BaHDC/KLDwozuV3pfgG5ae91FFgH1HFMrcHI6oc WdrY7d2tkb6poX9l5sI5l/8RlTGurdX4mY5d8NPWOPRCPOE2hsz7sCdKU5nicKlS1/1b rV6cruIKlWk1u8dt9Zu+eAmqp6n84fTalCzCsW43BxTYZSBU3fyJ2Js7rwaIHsghahvw drwg== X-Gm-Message-State: AC+VfDz26Q8YZ7Z4wiWHkS4KTHMbEmSaoe7judBwRJZ94ontOUXlBCg5 ecU6uS3ufnMdOMlQDWSK2kzT4Xax5BkKMWd8spZPOC12M3fngwNM9ppH6OcPv8u9MfH8+JpQREK f/GdfLgs4gY7iKmwAajY= X-Received: by 2002:a05:6808:2101:b0:397:fe89:202c with SMTP id r1-20020a056808210100b00397fe89202cmr21665730oiw.42.1687523158279; Fri, 23 Jun 2023 05:25:58 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5zJgz9+e09gwnFHtw4gRbDWdbSRbD8rz/lf/lUiBfsEVlMjcG5pKL+jCkUGq1pXL1pIT2EjQ== X-Received: by 2002:a05:6808:2101:b0:397:fe89:202c with SMTP id r1-20020a056808210100b00397fe89202cmr21665723oiw.42.1687523157975; Fri, 23 Jun 2023 05:25:57 -0700 (PDT) Received: from [192.168.0.241] ([198.48.244.52]) by smtp.gmail.com with ESMTPSA id f6-20020a816a06000000b0056ca07bbc03sm2426173ywc.86.2023.06.23.05.25.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Jun 2023 05:25:57 -0700 (PDT) Message-ID: <3429a7a6-2b6f-42f8-6e55-14d3e4561995@redhat.com> Date: Fri, 23 Jun 2023 08:25:56 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: build-many-glibcs.py build failure for i686-gnu To: Sergey Bugaev , libc-help Cc: Joe Simmons-Talbott References: <20230622195952.GL6392@oak> From: Carlos O'Donell Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 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) > > #else /* MACH_KERNEL */ > > 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 <80><98>_hurdsig_fault_catch_exception_raise<80><99>; have >>> <80><98>kern_return_t(mach_port_t, thread_t, task_t, integer_t, integer_t, long_integer_t)<80><99> {aka >>> <80><98>int(unsigned int, unsigned int, unsigned int, int, int, long int)<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 <80><98>_hurdsig_fault_catch_exception_raise<80><99> with type <80><98>kern_return_t(mach_port_t, mach_ >>> port_t, mach_port_t, integer_t, integer_t, integer_t)<80><99> {aka <80><98>int(unsigned int, unsigned int >>> , unsigned int, int, int, int)<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.