From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) by sourceware.org (Postfix) with ESMTPS id 9534E3858401 for ; Mon, 8 Nov 2021 13:54:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9534E3858401 Received: by mail-ot1-x32b.google.com with SMTP id g25-20020a9d5f99000000b0055af3d227e8so21192258oti.11 for ; Mon, 08 Nov 2021 05:54:42 -0800 (PST) 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:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=wJgPA9kgQm3nA+fYPSRcAQB0O/J0VV8hfcQ1kgS9Efk=; b=zUnzCagKdXHrX9sU1w342eAxnEZY4JbfnW2eN27+hrPfPSbabpdX1D4RA4lQ8sTrwp CZqyDKV6jJNTy+xfvk5L1jlRtUjfFOR7zM0/77G2QX/dAEawsOQvCMZzzRWofb1adyc0 RZcrfYil4QyImTZ0Qj+LswXyZu7D5YrEORDBkekkfroeP52ugT8U6jWOLMIYDReO/0ms LjL+okQaPgKoocWKdTqiEpypARodbcvK/QLpTtm5rE2tIsy4uaqWZwZZ1gX4HvKNjCMV JGdrrfJIT1y0oxLFgu5S1Xje9NJsHve6ItpZkjfLSPJfNshVT1jzt/C6hMxU2jmG2E5y 9mTA== X-Gm-Message-State: AOAM531FrYwjTjBsaIysAXle6LDqV9/YbDMCwrwpf9wVmxuqERdoSfaY nnSS3uGdddR5c3Y/iY1w/zHtug== X-Google-Smtp-Source: ABdhPJwzeK3qrTLqjuoDx1aDI2mTEmw5egJ26qVAgP40jxRfMZlhCulshuqpAIg40XAQbN+4XU7BDw== X-Received: by 2002:a05:6830:3101:: with SMTP id b1mr44457800ots.113.1636379681928; Mon, 08 Nov 2021 05:54:41 -0800 (PST) Received: from ?IPV6:2804:431:c7cb:55a:c067:29b:4c08:be99? ([2804:431:c7cb:55a:c067:29b:4c08:be99]) by smtp.gmail.com with ESMTPSA id l19sm1013540ooq.17.2021.11.08.05.54.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Nov 2021 05:54:41 -0800 (PST) Message-ID: <544b1d1d-e9d2-b03b-a882-ec60848ddc68@linaro.org> Date: Mon, 8 Nov 2021 10:54:39 -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 To: wschmidt@linux.ibm.com, Fangrui Song , Tulio Magno Quites Machado Filho , Alan Modra , Nemanja Ivanovic 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> <44162ce5-f791-e659-c8e5-130d3f2f694c@linaro.org> <889a40d5-5bb7-c0cd-2ebe-849c80a2780b@linux.ibm.com> From: Adhemerval Zanella In-Reply-To: <889a40d5-5bb7-c0cd-2ebe-849c80a2780b@linux.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: Mon, 08 Nov 2021 13:54:44 -0000 On 08/11/2021 10:26, Bill Schmidt wrote: > On 11/8/21 5:37 AM, Adhemerval Zanella wrote: >> >> On 07/11/2021 11:24, Bill Schmidt wrote: >>> Please coordinate with Alan Modra and Nemanja Ivanovic on this topic.  There are ongoing discussions about bfd and lld linker support around @notoc that will be resolved soon, and Tulio is on vacation, so I don't want the community to make steps they'll have to undo later, or for people to engage in duplicate work. >> For this specific issue I just sent a patch to fix it on glibc side [1]. >> However I think it would be good if lld also implements the ld.bfd >> optimization to fallback to older stub generation if no pcrel relocation >> is found (although it is debatable that @notoc should implicit generate >> older ISA code depending of the resulting objects being linked against). >> >> [1] https://patchwork.sourceware.org/project/glibc/patch/20211108113316.8867-1-adhemerval.zanella@linaro.org/ > > Hi Adhemerval, > > Current course and speed is that @notoc will imply pcrel stubs on P10 and later, > but will not do so on P9 and earlier. The relocation currently associated with > @notoc actually came with ELFv2 on P8 and, although no compilers ever generated > @notoc, assembly routines using it prior to P10 are a valid case and should not be > punished. This can be handled by generating a different reloc for @notoc in the > two cases. > > If this solution holds up, then changes to glibc should be unnecessary. The main problem is this imposes an extra burden for the linker, where it need to implement the ld.bfd optimization to not generate the power10 stubs if no pcrel is found. And it seems that lld does not yet support this yes and I guess it has not been an issue because @notoc in assembly routines should be rare. It also means that stubs generation are subject to a combination of relocation on different objects (@notoc on assembly does not necessary generate power10 stub with default linker option). I think it should be ok, although I see this as really confusing since it took some time to figure out what ld.lfd was doing.