From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) by sourceware.org (Postfix) with ESMTPS id 04ADD3857822 for ; Tue, 5 Apr 2022 16:44:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 04ADD3857822 Received: by mail-lj1-x234.google.com with SMTP id q14so17833189ljc.12 for ; Tue, 05 Apr 2022 09:44:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=OETSMiVYhE5CIDOaNmzH6O0VI2p3r+SblHLC6oNHNcc=; b=i4h2QKP+2x9d4UlozJOCmMqqufccI0Cvgyo2bMoG4RqQHckiuJHnnaXN158hkaiwOZ D6N3VW4oOkZ8MK8y3fp3wMz5Y8x0lhzX+MozJfhvv5hnybOGXWNZL/puX4gdrECBKM5z 5pzgvY4WdwW/GIWM3gUFxEpidgAnpJ83AfcmA8xw+oZvyeVsDFp8kGY2aRrXD3S/MGWQ LmJqWykE5iWWkBLS/1K/bHy08GU4r3+NzxgwcWXNkeRGSh4x+U6wgMdqDInn7CLVMLvw aBxAEuwccs9TDtxjNIdWTa0yw724VFNpqfAq+L+uP4ocfW4yJETZtouB76NRrw9LwjS7 jw3A== X-Gm-Message-State: AOAM5319nqNSYIT/Zj/05DReE4fKNZbrleSV4ihDvMUvf5JnmPZN2aHE vm1t83GY3H+UGbS8VopviRR1lFwwQkZ5Fhox5uYPofPp7tmj6A== X-Google-Smtp-Source: ABdhPJzN3JZTv103aKFnFaOq4isgAOMr2XaeVxAOVmp5hKdS+KJVNrdnbJWcT0oh215dcbzBhGrUSqIrQLonbvofTbs= X-Received: by 2002:a2e:a7ca:0:b0:249:85d4:faec with SMTP id x10-20020a2ea7ca000000b0024985d4faecmr2610117ljp.505.1649177058077; Tue, 05 Apr 2022 09:44:18 -0700 (PDT) MIME-Version: 1.0 References: <20220330050729.2176630-1-maskray@google.com> <0295bfe2-2f44-c15e-1628-acaf94fc407c@linaro.org> <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> In-Reply-To: <4570fa06-24b0-873a-09b6-d57c85dd1191@linaro.org> From: =?UTF-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Date: Tue, 5 Apr 2022 10:44:05 -0600 Message-ID: Subject: Re: [PATCH] Remove fno-unit-at-a-time make variable To: Adhemerval Zanella Cc: libc-alpha@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-18.6 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: Tue, 05 Apr 2022 16:44:22 -0000 On Tue, Apr 5, 2022 at 10:40 AM Adhemerval Zanella wrote: > > > > On 05/04/2022 13:22, F=C4=81ng-ru=C3=AC S=C3=B2ng 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/1868= 01.html). > >>>>>>>>> > >>>>>>>>> The reordering requirement does not seem to be needed any longe= r. > >>>>>>>> > >>>>>>>> We still need them for otherwise DEFINE_COMPAT_ERRLIST used on e= rrlist-compat.c > >>>>>>>> does not create _sys_errlist and _sys_siglist with expected size= s defined by > >>>>>>>> glibc ABI. > >>>>>>>> > >>>>>>>> I am trying to fix without resorting to compiler options. > >>>>>>> > >>>>>>> DEFINE_COMPAT_ERRLIST does not expand to code/data, just reordeab= le 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=3D29012 with detail= ed > >>>>> 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/bugzill= a/show_bug.cgi?id=3D29012 > >>> (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 nearb= y > >>> code, you may drop -fno-unit-at-a-time. It was added in 2006 (somewhe= re > >>> between GCC 4.1 and 4.4), while glibc requires GCC>=3D6.2. > >> > >> Good to know we won't need to rely on compiler flags to get the expect= ed > >> correct asm directives. I am still struggling to get a fix without res= orting > >> to compiler flags, but without much success. Trying to move it to ass= embly > >> might be tricky, I am not sure if the data directives would be archite= cture > >> 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=3D29012#c1