From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) by sourceware.org (Postfix) with ESMTPS id 459F63858405 for ; Thu, 7 Apr 2022 07:02:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 459F63858405 Received: by mail-pl1-x62e.google.com with SMTP id f10so4080518plr.6 for ; Thu, 07 Apr 2022 00:02:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=0X4Ez9c9iofXj4xoqs5cys22m4J6oVFMVPbMQFyl84I=; b=DxrH1Cv7uYqQx7Oci5bH4BwRCy3x0Fw8UmPqX9A3sVTczEDes1AI3yxdqIiuTYzUTa mqCfOo1Ci56MvjUSu1xBNPZILBSjYKtlFzwfTZ/oiphsmOsXzP4B6Gq+u0E2idj4DNNW FDffIObp3FnD2lOjUdGNckYDYT5EdqlodqqmLzyvHWXJ0cR3YfHL0hOey6hwIqIYz9oe hfZulJz5QQ3LCPL8RL7qSg+401AUi9Mhv7OT1h/ZXC2phlkQUtUAZRdmL8ov16cYlIRf hdwhZQVL5RIeYp6oBi2RGEOdKnK3d3oDviXOPAvgU4CdPEZW94Hbk4KGn6thkIDdFfsh e0JA== X-Gm-Message-State: AOAM530JeGVUg+rwO2FMdZRPzCZf3Yph4KnascItaT/pcTIYK7w/68wB K3IQR1QZJSqWDgh7BUfoUKckXiRxlIZ6bw== X-Google-Smtp-Source: ABdhPJwdMPhVBW5HYGJV/ODMRFWOViTzkSfziBRoK9lEeqf+Hj0Z7IE7lAuiwMtsUN5uQnNTjBvEWQ== X-Received: by 2002:a17:90b:1b4d:b0:1c6:bd9e:a63d with SMTP id nv13-20020a17090b1b4d00b001c6bd9ea63dmr14359919pjb.56.1649314976977; Thu, 07 Apr 2022 00:02:56 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:9e1b:ac4c:d159:5eae]) by smtp.gmail.com with ESMTPSA id h10-20020a056a00230a00b004faa0f67c3esm20382600pfh.23.2022.04.07.00.02.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Apr 2022 00:02:56 -0700 (PDT) Date: Thu, 7 Apr 2022 00:02:53 -0700 From: =?utf-8?B?RsSBbmctcnXDrCBTw7JuZw==?= To: Adhemerval Zanella Cc: libc-alpha@sourceware.org Subject: Re: [PATCH] Remove fno-unit-at-a-time make variable Message-ID: <20220407070253.ixzacw4buw6aekor@google.com> References: <20220330162311.pwg52gcrr5vnlabe@google.com> <7e7fdfdc-ddc8-cf5a-0525-f927b4ae1e39@linaro.org> <20220331034302.rzcu6gllo7ltkhjh@google.com> <20220404155703.vefk66cwnsnkhsih@google.com> <22f8e3aa-5af9-93a2-65fc-1889674103d6@linaro.org> <4570fa06-24b0-873a-09b6-d57c85dd1191@linaro.org> <914158c4-f52d-21ee-73e5-6ffe30faa0d4@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <914158c4-f52d-21ee-73e5-6ffe30faa0d4@linaro.org> X-Spam-Status: No, score=-19.8 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 07:03:00 -0000 On 2022-04-05, Adhemerval Zanella wrote: > > >On 05/04/2022 13:44, Fāng-ruì Sòng wrote: >> On Tue, Apr 5, 2022 at 10:40 AM Adhemerval Zanella >> wrote: >>> >>> >>> >>> On 05/04/2022 13:22, Fāng-ruì Sòng wrote: >>>> On Tue, Apr 5, 2022 at 8:35 AM Adhemerval Zanella >>>> wrote: >>>>> >>>>> >>>>> >>>>> On 04/04/2022 12:57, Fangrui Song wrote: >>>>>> >>>>>> On 2022-03-31, Adhemerval Zanella wrote: >>>>>>> >>>>>>> >>>>>>> On 31/03/2022 00:43, Fangrui Song wrote: >>>>>>>> On 2022-03-30, Adhemerval Zanella wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 30/03/2022 13:23, Fangrui Song wrote: >>>>>>>>>> On 2022-03-30, Adhemerval Zanella wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 30/03/2022 02:07, Fangrui Song wrote: >>>>>>>>>>>> 795985e4e751 in 2003 added -fno-unit-at-a-time to errlist.c and >>>>>>>>>>>> siglist.c to "avoid reordering assembler output". -fno-toplevel-reorder >>>>>>>>>>>> is a rough replacement for this legacy option >>>>>>>>>>>> (https://sourceware.org/pipermail/gcc-patches/2006-January/186801.html). >>>>>>>>>>>> >>>>>>>>>>>> The reordering requirement does not seem to be needed any longer. >>>>>>>>>>> >>>>>>>>>>> We still need them for otherwise DEFINE_COMPAT_ERRLIST used on errlist-compat.c >>>>>>>>>>> does not create _sys_errlist and _sys_siglist with expected sizes defined by >>>>>>>>>>> glibc ABI. >>>>>>>>>>> >>>>>>>>>>> I am trying to fix without resorting to compiler options. >>>>>>>>>> >>>>>>>>>> DEFINE_COMPAT_ERRLIST does not expand to code/data, just reordeable directives: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> .globl __GLIBC_2_1_sys_errlist >>>>>>>>>> .set __GLIBC_2_1_sys_errlist, _sys_errlist_internal >>>>>>>>>> .type __GLIBC_2_1_sys_errlist,@object >>>>>>>>>> .size __GLIBC_2_1_sys_errlist, 1000 >>>>>>>>>> .globl __GLIBC_2_1__sys_errlist >>>>>>>>>> .set __GLIBC_2_1__sys_errlist, _sys_errlist_internal >>>>>>>>>> .type __GLIBC_2_1__sys_errlist,@object >>>>>>>>>> .size __GLIBC_2_1__sys_errlist, 1000 >>>>>>>>>> .symver __GLIBC_2_1_sys_nerr, sys_nerr@GLIBC_2.2.5 >>>>>>>>>> .symver __GLIBC_2_1__sys_nerr, _sys_nerr@GLIBC_2.2.5 >>>>>>>>>> .symver __GLIBC_2_1_sys_errlist, sys_errlist@GLIBC_2.2.5 >>>>>>>>>> .symver __GLIBC_2_1__sys_errlist, _sys_errlist@GLIBC_2.2.5 >>>>>>>>>> .globl __GLIBC_2_3_sys_errlist >>>>>>>>>> .set __GLIBC_2_3_sys_errlist, _sys_errlist_internal >>>>>>>>>> .type __GLIBC_2_3_sys_errlist,@object >>>>>>>>>> .size __GLIBC_2_3_sys_errlist, 1008 >>>>>>>>>> .globl __GLIBC_2_3__sys_errlist >>>>>>>>>> .set __GLIBC_2_3__sys_errlist, _sys_errlist_internal >>>>>>>>>> .type __GLIBC_2_3__sys_errlist,@object >>>>>>>>>> .size __GLIBC_2_3__sys_errlist, 1008 >>>>>>>>>> .symver __GLIBC_2_3_sys_nerr, sys_nerr@GLIBC_2.3 >>>>>>>>>> .symver __GLIBC_2_3__sys_nerr, _sys_nerr@GLIBC_2.3 >>>>>>>>>> .symver __GLIBC_2_3_sys_errlist, sys_errlist@GLIBC_2.3 >>>>>>>>>> .symver __GLIBC_2_3__sys_errlist, _sys_errlist@GLIBC_2.3 >>>>>>>>>> .globl __GLIBC_2_4_sys_errlist >>>>>>>>>> >>>>>>>>>> I do not know whether GCC would reorder these macros. Even yes, >>>>>>>>>> that'd just change the .symtab entries in the relocatable object file. >>>>>>>>>> The linker behavior remains the same with reordering. >>>>>>>>> >>>>>>>>> It does not seem to, just remove the -fno-unit-at-a-time and issue make >>>>>>>>> check-abi and you will see that object size for the compat symbols >>>>>>>>> reference to _sys_err_internal instead of the define compat ones. >>>>>>>> >>>>>>>> I see. I think this is a brittle behavior in GNU assembler. Filed >>>>>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=29012 with detailed >>>>>>>> information. I have created a patch but I know that will not solve >>>>>>>> glibc's problem :( >>>>>>> >>>>>>> It would be good to have this fixes, but unfortunately we need a way >>>>>>> to handle this on older binutils. I am kind worried that the only >>>>>>> possible way to actually fix this without resorting to any compiler >>>>>>> flags is coding the array definitions in assembly direct... >>>>>> >>>>>> The GNU assembler issue has been fixed https://sourceware.org/bugzilla/show_bug.cgi?id=29012 >>>>>> (milestone 2.39, way larger than the current required version: 2.25) >>>>>> >>>>>> Switching to assembly output doesn't seem bad :-) >>>>>> >>>>>> If you keep the compiler driver option but need to refactor the nearby >>>>>> code, you may drop -fno-unit-at-a-time. It was added in 2006 (somewhere >>>>>> between GCC 4.1 and 4.4), while glibc requires GCC>=6.2. >>>>> >>>>> Good to know we won't need to rely on compiler flags to get the expected >>>>> correct asm directives. I am still struggling to get a fix without resorting >>>>> to compiler flags, but without much success. Trying to move it to assembly >>>>> might be tricky, I am not sure if the data directives would be architecture >>>>> agnostic. >>>> >>>> Many directives are architecture-independent: >>>> https://sourceware.org/binutils/docs/as/Pseudo-Ops.html#Pseudo-Ops >>>> binutils-gdb/gas/read.c:346 The `portable[]` array. >>> >>> I think we can make it work with asciz directive. >>> >>>> >>>> To support Clang, no refactoring is probably needed: just change >>>> fno_unit_at_a_time to only specify -fno-toplevel-reorder (and rename >>>> it), not th legacy -fno-unit-at-a-time. >>> >>> Afaik llvm does not support -fno-toplevel-reorder >> >> It doesn't, but its integrated assembler does not need the option to >> have the desired semantics. I have a note that the new GNU as behavior >> is quite similar to LLVM's integrated assembler since 2014-03: >> https://sourceware.org/bugzilla/show_bug.cgi?id=29012#c1 > >This is not what I am seeing on my clang branch, where clang with integrated >moves the global asm directives to the top of the file. And it makes >check-abi fail due the _sys_errlist/sys_errlist being with wrong value. I see. For gas/testsuite/gas/elf/size.s, LLVM integrated assembler's behavior matches GNU as. The glibc errlist.os example is more complex due to a symbol assignment implied by .symver . https://reviews.llvm.org/D123283 should fix it. It isn't a perfect fix but works with most cases. I can request a backport to LLVM 14.0.1 if it lands.