From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) by sourceware.org (Postfix) with ESMTPS id 1A2513858D28 for ; Fri, 5 Nov 2021 19:32:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1A2513858D28 Received: by mail-ot1-x330.google.com with SMTP id l7-20020a0568302b0700b0055ae988dcc8so11402918otv.12 for ; Fri, 05 Nov 2021 12:32:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:from:to:cc:references:in-reply-to :content-transfer-encoding; bh=9g1L9bE+ujHbX4lb+LNrlaz/0NNjfjEb9HfUbmYznHM=; b=Q3fnFPytGcjG5P2sML1CI4mbv1D+dJ+BWPYAP7OUAhYtx09Ry7N6tYGf8zYNTvJyfh GgkfqZUR3HLWoaMWpb4G8R6JmRGwUV4e+4ewkTg6HE9UAXWbEVsCNcVNU9KA/Yc87+Z5 rH2624a2khUq0LgL5WxqQyqaNrQ+NhAkwvZ6ezf1+vLUFM/j3WaU/UtdLCWqAApFDiew lCpuoZ9VhzAp4THJB3zIZZoXTykRppzVRc4e02nsBc4HPjMV9nY4wy2ocB2wYpa6gs6c O/xHYTmJWrojx7huEZAz1m1NrstMcp3fm9g+Nl9zwYv5ouoirCJAGZ1Xr1hc/2tUBmLx aKXA== X-Gm-Message-State: AOAM533OF2b509Q1tJWHQM9hQeQ6DHEoo6bp3KXwdBOUI7TN1I21LpP+ j81APQQ+1pMV4SUNRDssVCuoZQ== X-Google-Smtp-Source: ABdhPJwv+JBxwbQ1E1iMgJ1o0KfY7BoPPLpH7FhgQ518vj+b1gOiOnduT2EV45wkJQxt8vNTJJLO2g== X-Received: by 2002:a9d:57c4:: with SMTP id q4mr9347840oti.175.1636140768233; Fri, 05 Nov 2021 12:32:48 -0700 (PDT) Received: from ?IPV6:2804:431:c7cb:55a:c916:e574:3d13:f60c? ([2804:431:c7cb:55a:c916:e574:3d13:f60c]) by smtp.gmail.com with ESMTPSA id j7sm2793258otn.59.2021.11.05.12.32.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Nov 2021 12:32:47 -0700 (PDT) Message-ID: Date: Fri, 5 Nov 2021 16:32:45 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Subject: Re: lld status with powerpc64 Content-Language: en-US From: Adhemerval Zanella To: Fangrui Song , Tulio Magno Quites Machado Filho Cc: libc-alpha@sourceware.org References: <20211026200346.3371750-1-adhemerval.zanella@linaro.org> <20211026203327.6b2o5k4cmkuzzm6j@google.com> <87lf2ejdnw.fsf@linux.ibm.com> <87ilxijd5f.fsf@linux.ibm.com> <20211105072312.wbqrhgyjvsypkj52@google.com> <35b483cc-fb4e-6770-bff2-aebb5f178614@linaro.org> In-Reply-To: <35b483cc-fb4e-6770-bff2-aebb5f178614@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_INFOUSMEBIZ, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP 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: Fri, 05 Nov 2021 19:32:52 -0000 On 05/11/2021 10:58, Adhemerval Zanella wrote: > So we have two options here: > > 1. Do not define USE_PPC64_NOTOC if with-lld (not optimal if ldd > aims to support such behavior). > > 2. Define USE_PPC64_NOTOC iff linker supports such optimization. > It means to emit a NOTOC relocation (R_PPC64_REL24_NOTOC), > link a simple binary without any pcrel and check if the stub has > power10 instruction. > > 3. Remove the USE_PPC64_NOTOC usage. It is used on setjmp routines > and on the syscall definition to call the __syscall_error. > > I am aiming to implement 2. since at least by disabling USE_PPC64_NOTOC > manually on config.h when configuring with lld I can build glibc. > >> >> >> In my testing environment (POWER9), ld.bfd doesn't support @notoc, so >> USE_PPC64_NOTOC is undefined. >> >> % gcc --version >> gcc (Debian 8.3.0-6) 8.3.0 >> ... >> % ld.bfd --version >> GNU ld (GNU Binutils for Debian) 2.31.1 >> ... >> >> I only see 8 more FAILs with ld.lld than ld.bfd > > I am still having trouble to *finish* make check with lld release 13 > my environment (some tests stuck on infinite loop). > >> >> >> % diff -u 0 1 >> --- 0   2021-11-05 00:11:43.218731302 -0700 >> +++ 1   2021-11-05 00:11:37.659286448 -0700 >> @@ -9,6 +9,14 @@ >>  FAIL: debug/tst-lfschk6 >>  FAIL: dlfcn/bug-atexit3 >>  FAIL: elf/check-abi-libc >> +FAIL: elf/ifuncmain1pic >> +FAIL: elf/ifuncmain1pie >> +FAIL: elf/ifuncmain1vis >> +FAIL: elf/ifuncmain1vispic >> +FAIL: elf/ifuncmain1vispie >> +FAIL: elf/ifuncmain3 >> +FAIL: elf/ifuncmain6pie >> +FAIL: elf/tst-tlsopt-powerpc >>  FAIL: nptl/tst-cancel24 >>  FAIL: nptl/tst-minstack-throw >>  FAIL: nptl/tst-once5 >> >> >> I suspect ifuncmain1* is again related to the order of R_*_IRELATIVE with >> regard to R_*_JUMP_SLOT referencing a STT_GNU_IFUNC symbol. >> (something like https://maskray.me/blog/2021-01-18-gnu-indirect-function#relocation-resolving-order) >> But perhaps Adhemerval can look a look at it. > > I still need to understand why armhf also fails with the ifunc using > protected symbols, although I am not if they are related to IRELATIVE > ordering. > >> >> >> For elf/tst-tlsopt-powerpc, it is simply because ld.lld doesn't implement the GNU ld powerpc64's >> __tls_get_addr_opt (pseudo-TLSDESC): https://maskray.me/blog/2021-02-14-all-about-thread-local-storage#powerpc-__tls_get_addr_opt >> Let me send a configure patch to disable it... >> >> Actually I do not know how to disable tst-tlsopt-powerpc properly. >> >> Perhaps add sysdeps/powerpc/configure.ac and move the >> sysdeps/unix/sysv/linux/powerpc/configure.ac --no-tls-get-addr-optimize >> to sysdeps/powerpc/configure.ac? >> sysdeps/powerpc/preconfigure.ac exists (I don't know how it is used). >> >> The patch requires some non-trivial configure.ac change, so I'd hope >> that an expert can do it > > Maybe just disable the test if __tls_get_addr_opt (pseudo-TLSDESC) is not supported > by the linker? > > >> >> >> Hey, so lld linked glibc powerpc64 is in a pretty good status! > > I am still not sure about it, I did could run some tests but I am still > struggling to get a make check to finish. > So it turned out the another issues was my gcc toolchain did not have initfini array set which lets to compiler generate .ctors instead of .init_array and lld does not support .ctors (it just ignores instead of converting to .init_array entries as bfd). With NOTOC fix and a proper toolchain I am seeing the same regression you are seeing: FAIL: elf/ifuncmain1pic FAIL: elf/ifuncmain1pie FAIL: elf/ifuncmain1vis FAIL: elf/ifuncmain1vispic FAIL: elf/ifuncmain1vispie FAIL: elf/ifuncmain3 FAIL: elf/ifuncmain6pie FAIL: elf/tst-tlsopt-powerpc I think it would be good use --enable-initfini-array on build-many-glibc.py until we set gcc-12 as default.