From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 731AF1F953 for ; Thu, 2 Dec 2021 22:08:28 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7CCAD385AC28 for ; Thu, 2 Dec 2021 22:08:26 +0000 (GMT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by sourceware.org (Postfix) with ESMTPS id C1ABA3858428 for ; Thu, 2 Dec 2021 22:08:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C1ABA3858428 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=jrtc27.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jrtc27.com Received: by mail-wr1-x436.google.com with SMTP id q3so1657064wru.5 for ; Thu, 02 Dec 2021 14:08:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jrtc27.com; s=gmail.jrtc27.user; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dA03KkYG4neLwZxqVrFdNUVF5kLDrPEbqQt9+cZzTcE=; b=CHtfi5uSYkhV1Pq15nBnqaysEKdX/Aiqu4LGJnyWYqX3PTCP6TYw238Xtq5baypMuc KMIjH9uLuu75PNqfH2G+cCqmBuS5RDPbCItEJgG1EbKNJP6LsVRefgJruqONzewlX3cs 3Eg9gOQ4KXl+ACBCaxDORir/lLMPUjeaiEGiN1+8G5Ek84bOF+eqkQdI4/Y5pBVmKDpc oZnaMVaW00ZWxgYzDotDUJ29uWPqilugieXS0rPpsz5u5c/qF3Fs7Fe5d3zU66StQ6VL Glj6BV7Y2/7aXdcx8otUcpDXR/GQrqPcKEeeNrlfperhIWj4tC2O4eqB3eJF14j4QHtU WBKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dA03KkYG4neLwZxqVrFdNUVF5kLDrPEbqQt9+cZzTcE=; b=xCzLDPZ3COqCXzSvon8bl8SByti0I3+LFt71SSIjlcllvPvz6bl5c3rYPobU7Bjdb1 6Rl1bxcy8w1qp0FGMdkb9pf2NML52g+9mEJ+CMm5WGF3r6od0Q+2e0ACwnV5XE/BBMxh s8rD5A9PKs4+Vm7JAMHtHHR9iAtN9CRh1Lumj0fHXR54hzrwIV6zk+6h3dPmXvLoeLEB DnEpQoc2A5o862pmjT0BztpEhJxy8EW+hFyGYeWmQLLQj8IxszNg0YwVeIP0RL064XGH atSRi7+Ji+HgzmBWlKGS3Cl7yV0yeHc9bx4rSatjxoXl/8+DPaGo+yGvceKlqZaJAfYV hFCQ== X-Gm-Message-State: AOAM530L5KCawRW0/HnYwfkDRuMRKkubTBt7lsj5pdVa02BD1rheCK96 GviiHuG3LKexri4tDM3mfEBAYg== X-Google-Smtp-Source: ABdhPJxhNp7HjhAUIvymHHDLYPxlt0WmFzJihPqR4Q3xlzAoJa0pF14e1K1D4YGbNDEclHd2tdv09A== X-Received: by 2002:a5d:6548:: with SMTP id z8mr18205655wrv.502.1638482892865; Thu, 02 Dec 2021 14:08:12 -0800 (PST) Received: from smtpclient.apple (global-5-141.nat-2.net.cam.ac.uk. [131.111.5.141]) by smtp.gmail.com with ESMTPSA id n7sm873915wro.68.2021.12.02.14.08.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Dec 2021 14:08:12 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: [PATCH] riscv: Resolve symbols directly for symbols with STO_RISCV_VARIANT_CC. From: Jessica Clarke In-Reply-To: <87r1auznpn.fsf@oldenburg.str.redhat.com> Date: Thu, 2 Dec 2021 22:08:10 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <60359D93-BA59-486D-BCD5-8EB582700FA9@jrtc27.com> <87r1auznpn.fsf@oldenburg.str.redhat.com> To: Florian Weimer X-Mailer: Apple Mail (2.3654.120.0.1.13) 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: , Cc: libc-alpha@sourceware.org, Kito Cheng , Andrew Waterman Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 2 Dec 2021, at 21:44, Florian Weimer wrote: >=20 > * Jessica Clarke: >=20 >> The intent of the spec is not to make repurposing just ra/sp/gp/tp as >> anything other than their ABI-defined meanings (per table 1 of = riscv-cc >> and, in the case of the stack pointer, the alignment required by the >> integer calling convention) legal unless you use = STO_RISCV_VARIANT_CC, >> so the glibc requirement, which is also true of FreeBSD for exactly = the >> same reasons, is intended to be what is specified. Upon re-reading = what >> was written I can see that requirement was lost or forgotten, so = I=E2=80=99ll >> look at tightening it up, probably changing >>=20 >> Any functions that use additional argument registers ... >>=20 >> to >>=20 >> Any functions that use registers in a way that is incompatible with >> the register convention of the ABI in use ... >>=20 >> I also note we currently only talk about the run-time linker = preserving >> argument registers, and say nothing about preserved registers, nor = the >> return address. I=E2=80=99m not sure quite why we do the former = (maybe I=E2=80=99ve >> just forgotten a past conversation), I feel like that=E2=80=99s = implied by lazy >> binding being an implementation optimisation that must not break the >> calling convention, but if we want to keep that language then it = should >> probably be changed to: >>=20 >> Run-time linkers that use lazy binding must only clobber registers >> defined as temporary registers for the ABI in use. >>=20 >> Does that all sound sensible, and sufficient, to you? >=20 > One further aspect is that glibc has dynamic linker plugins called > auditors, and arbitrary code can run *after* a function has returned. > For that to work, we need save registers used for return values as = well. > (The default dynamic linker trampoline sidesteps this because it makes = a > tail call to the actual implementation, based on what the core symbol > binding routine in the dynamic linker has returned.) This is a fairly > obscure feature, and I don't think anyone has a really good solution = for > their architecture today. There might also be better alternatives > (e.g., if you know the signature of the function you are intercepting, > you don't need a general solution for arbitrary calling conventions > anymore). >=20 > Do temporary registers overlap with return registers? The audit support in glibc is a good point, and something that hadn=E2=80=99= t even crossed my mind (though probably should have; I have used it). Short answer is it=E2=80=99s the like AArch64 (but no IP0/1 and veneer weirdness equivalents). Long answer is that the register convention currently defines registers as preserved across calls, not preserved across calls, and unallocatable (special case for gp and tp, as = =E2=80=9Cdon=E2=80=99t clobber unless you=E2=80=99re the runtime or otherwise really know what = you=E2=80=99re doing=E2=80=9D). Those registers not preserved across calls are further subdivided into argument registers, used for both arguments and return values, and temporary registers, which have no other defined role in the calling convention. Dealing with glibc=E2=80=99s auditing in the implementation-agnostic ABI = starts to become a bit awkward; in particular, interposing on the return requires clobbering the return address on the call path, which is not a temporary register, and so would not be legal per my suggested text, but you don=E2=80=99t want to give free reign for people to clobber it = because clearly that=E2=80=99s totally broken in almost other cases. Perhaps that=E2=80=99s an argument for dropping the first sentence = entirely, and just having the =E2=80=9CAny functions ...=E2=80=9D sentence, = possibly with a bit of extra non-normative text if it then looks lacking in rationale. Do you know if any other psABIs specify the requirements on run-time linkers like we=E2=80=99re currently trying (and failing) to do? Jess