From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) by sourceware.org (Postfix) with ESMTPS id 6EFD53858406 for ; Mon, 8 Nov 2021 14:11:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6EFD53858406 Received: by mail-ot1-x32d.google.com with SMTP id r10-20020a056830448a00b0055ac7767f5eso25670426otv.3 for ; Mon, 08 Nov 2021 06:11:13 -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=AbvGXrhw1B9BTOXx9MGFNpENFH2+h7qB29i+5fKGMok=; b=jcZH1B5voUWRV2t1qmB8k1UIt0URxKGmRDlEYryu2FKaFGrt2GDu0itlU8cb07VFrL q/fAfwm//yhCx1zKRLgn1qQh37uUO+HoHQ0FyQwTiqXC/G1U2V7SIUC+yWW3lbNPYmx+ I0fxftKIODNZ9LvJhzcXc27M4DICmR5scW5uwWLFm0Oucb3m3+VxTWO5xd5hxAvTudhI fgIr9Jk9o9piVxAzPE9IGLZytMJLpeOqSrnKNpBxESSTdsnLhzk2RAN3Zy4pPAaYLag8 VlL3N6FOeOCvHduhfTBA6bdjQRLHGx6GH9YIdNaj+KOZ6ICTVWAEiNm8odWWGA1N2BwP PvFw== X-Gm-Message-State: AOAM531xut4UYmI4kxFXNKNyc388pWtwMUsfXqGvjeUtzOq5AEMn89eu o9bddYehCCdZ1Q0MYOs40cEs/A== X-Google-Smtp-Source: ABdhPJyIMFp/KM5Hh8isBhtLgY7d+DaTjEoeajPaKra6fWX8kJgHG9fC5SpoWWUPSfq8ChDi8U6etQ== X-Received: by 2002:a9d:2f61:: with SMTP id h88mr92483otb.36.1636380672478; Mon, 08 Nov 2021 06:11:12 -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 g10sm1369214otg.10.2021.11.08.06.11.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Nov 2021 06:11:12 -0800 (PST) Message-ID: <1d07a810-e8dc-a3e3-ba31-5f50610c18e5@linaro.org> Date: Mon, 8 Nov 2021 11:11:09 -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> <544b1d1d-e9d2-b03b-a882-ec60848ddc68@linaro.org> From: Adhemerval Zanella In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.4 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 14:11:15 -0000 On 08/11/2021 10:59, Bill Schmidt wrote: > On 11/8/21 7:54 AM, Adhemerval Zanella wrote: >> >> 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. > > My only point is that the linker teams from both groups have been huddling about > this, so I wanted you to be aware the issue goes a little deeper than it appears > on the surface. How glibc deals with this is up to glibc, of course. :) > Well, my patch had to disable notoc exactly because lld version does not support such optimization (so default builds always use power10 instruction). It means that lld powerpc64le support is either incomplete or @notoc handling need to be clarified.