From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) by sourceware.org (Postfix) with ESMTPS id D347D3858401 for ; Tue, 21 Dec 2021 14:37:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D347D3858401 Received: by mail-qv1-xf36.google.com with SMTP id o10so12591966qvc.5 for ; Tue, 21 Dec 2021 06:37:49 -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=XEeTdCLVkWCA2X8eMxGxSGtuTyLWmqGJpzK0ixQ2LLE=; b=oLAEfEYdMC1brxAkxF7tKCo906FsR/0GKL50YiTufyXzrHio1J3tKovxVNtXKXg+0o hNU1oLBU9nw2T1kJJAR3DLQzWaS1prhJ007vNjLzYvUax1U7a0HPKD9BlS69luQuOtGa oM0Pi6aRd+ZkQyWz5PklwPy67VmWw/pz4PkcJsZzc+0MyI4Cs4Urpit8AZx0Ymn3iwmG oPCA0bWKzdVVofpcPJ4ecWPIOJezzGukvDSuAJE790PtX/AUUbrQbcNOmkYjmpqpuqRo A91I7jeppwE7jmUdyl1yDMkdhsp673UrCrkY2l0WPmlLASK2xPHk+ywpDYDVcq4/6nEW qmFQ== X-Gm-Message-State: AOAM530PeZLh2gH8OhBINL4zBh9TW/a71iUG40xwieeLcH/1f81svTQo b8s9mtNGP6nnweAl70vDH83+CX1delQVbA== X-Google-Smtp-Source: ABdhPJwZWdEpiKT2791gxUa4yGEguoTucuo0N1TeQA7SaB2Gn6kYAW/WvIzbqwCtH1DK9Kvdl4OpDA== X-Received: by 2002:ad4:5f8c:: with SMTP id jp12mr2531065qvb.68.1640097469443; Tue, 21 Dec 2021 06:37:49 -0800 (PST) Received: from ?IPV6:2804:431:c7cb:3b1e:8bd2:32a9:e2a3:1842? ([2804:431:c7cb:3b1e:8bd2:32a9:e2a3:1842]) by smtp.gmail.com with ESMTPSA id z4sm17646052qtj.42.2021.12.21.06.37.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Dec 2021 06:37:49 -0800 (PST) Message-ID: <624f4f61-b7e2-407e-dd83-e4db1e0f4148@linaro.org> Date: Tue, 21 Dec 2021 11:37:46 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH v6 20/20] elf: Add SVE support for aarch64 rtld-audit Content-Language: en-US To: Florian Weimer , Szabolcs Nagy Cc: libc-alpha@sourceware.org, John Mellor-Crummey , Ben Woodard References: <20211115183734.531155-1-adhemerval.zanella@linaro.org> <20211115183734.531155-21-adhemerval.zanella@linaro.org> <87r1a69gnl.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella In-Reply-To: <87r1a69gnl.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: Tue, 21 Dec 2021 14:37:51 -0000 On 21/12/2021 11:27, Florian Weimer wrote: > * Adhemerval Zanella: > >> To implement lazy binding is enabled when profiling or auditing used, >> even when STO_AARCH64_VARIANT_PCS is set. Also, to not incur in >> performance penalties on architecture without SVE, the PLT entrypoint >> is set to a newer one, _dl_runtime_profile_sve, which is used iff >> 'hwcap' has HWCAP_SVE bit set. >> >> This should be a fair assumption since SVE has a defined set of >> registers for argument passing and return values. A new ABI with either >> different argument passing or different registers would require a >> different PLT entry, but I assume this would require another symbol flag >> anyway (or at least a different ELF mark to indicate so). > > Someone familiar with SVE needs to review this. > > The restriction to the currently-specified vector calling convention > seems to be a bit arbitrary to me. To me, STO_AARCH64_VARIANT_PCS > strongly suggests that the toolchain makes every conceivable attempt to > support arbitrary calling conventions, but that's probably just me. The STO_AARCH64_VARIANT_PCS does suggest compiler might use *any* calling convention it seems fit for the symbol. I sent the patch initially as RFC, hopping other ARM developers will suggest that either assuming SVE calling convention would be fine or if we should not make any assumptions and save/restore everything. I can remove it from this patchset and aim to fix on 2.36. The main problem is would require to bump LAV_VERSION again for aarch64, since it would require change both La_aarch64_regs and La_aarch64_retval layout.