From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BF155C41513 for ; Mon, 7 Aug 2023 15:27:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230120AbjHGP1t (ORCPT ); Mon, 7 Aug 2023 11:27:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51236 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230131AbjHGP1q (ORCPT ); Mon, 7 Aug 2023 11:27:46 -0400 Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4CFAB1721 for ; Mon, 7 Aug 2023 08:27:40 -0700 (PDT) Received: by mail-qv1-xf2d.google.com with SMTP id 6a1803df08f44-63d30b90197so28455246d6.0 for ; Mon, 07 Aug 2023 08:27:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1691422059; x=1692026859; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=dUwZAwY3w/DCovXOhpFaYpG5BJu/scVYyvQE2nkhLjk=; b=ZWONZDbN4DLl+GxuPDPb/kn5iUAK3wkJvTpyZc/I7t8nLVCDHq2ZUaCzaEQuUmk0Z3 FFH5Jy/FCYU7NiHCsaWnsZTfgKzvSEgCW+jdZI978Hx3OIc+KK8BVtHtOAvxkmqsMAO+ +BvlMicPvzgF/8u7YljscTAnlgLUHcQ8qY9ar/ixqFNLXc7BiPGedFRdgbGnXtY8aTOU sQ83vU/dSwG3USoQSXU6I1e4FCZvhGpYR3DDEGMJ00z1P8XCjSc5JZa00wGMNlQlKttO o2PoISTP8orIkHdyWKCib5MXsvGIo5oY8KQTKPPsPNLyS6LIxu8K+GCS4Qf45pyp750u VxLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691422059; x=1692026859; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dUwZAwY3w/DCovXOhpFaYpG5BJu/scVYyvQE2nkhLjk=; b=WhuX3RighUjfqDQhvcGjPq5nLvKU2MlHyFJAG0VKT0Rfl1LNJE1N7OFQ4ES01g+6P5 P3uGiB9cMdZ42SoHSrpZEzfHrcVrN1EnT7NLbV23E96bLSRIQRy95wvacqU5rjC8AJyv +K4pe2B7C9GAUuwoAgPwtJIihTEKuEOKxruxBVorI2igmFJ/6IIO2YPXsrfw6Sp48hAt hfCreuO3HLLgKNI1qTXEiPhQU3T+ReyDPpCEUvYNdZMT3SW3cOgbg7DauFq8GtOFXw4E aOmqt/3A6qyRtBFuVMMWQhv9Nyy2EhtYQS/PtObtg3HWOBqC7dDC2EUXmxdNMwJzh+8m dB2A== X-Gm-Message-State: AOJu0YyGvS8Kh4ln/poY+Nyk6UsMgzLilOBzV0OrSo0VFFIiOplfEpRV mpkhTstv0ZbQp8Jj08PagUSL+/B/MrzM+nS5QFIEVw== X-Google-Smtp-Source: AGHT+IGoaH+s4R0EmOFvCPGZkJiL5/BBp3MuHbjbOs5J/ajqWaKGRjUz2hwympLNGjtDR6ahbq+YlO+vvxuAv1fnkUU= X-Received: by 2002:a05:6214:580b:b0:63d:36ab:93e6 with SMTP id mk11-20020a056214580b00b0063d36ab93e6mr9060294qvb.65.1691422059150; Mon, 07 Aug 2023 08:27:39 -0700 (PDT) MIME-Version: 1.0 References: <20230804090621.400-1-elver@google.com> <87il9rgjvw.fsf@oldenburg.str.redhat.com> In-Reply-To: <87il9rgjvw.fsf@oldenburg.str.redhat.com> From: Nick Desaulniers Date: Mon, 7 Aug 2023 08:27:27 -0700 Message-ID: Subject: Re: [PATCH v2 1/3] compiler_types: Introduce the Clang __preserve_most function attribute To: Florian Weimer Cc: Marco Elver , Andrew Morton , Kees Cook , Guenter Roeck , Peter Zijlstra , Mark Rutland , Steven Rostedt , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Nathan Chancellor , Tom Rix , Miguel Ojeda , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, llvm@lists.linux.dev, Dmitry Vyukov , Alexander Potapenko , kasan-dev@googlegroups.com, linux-toolchains@vger.kernel.org, Jakub Jelinek , Greg KH Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Mon, Aug 7, 2023 at 4:41=E2=80=AFAM Florian Weimer = wrote: > > * Marco Elver: > > > [1]: "On X86-64 and AArch64 targets, this attribute changes the calling > > convention of a function. The preserve_most calling convention attempts > > to make the code in the caller as unintrusive as possible. This > > convention behaves identically to the C calling convention on how > > arguments and return values are passed, but it uses a different set of > > caller/callee-saved registers. This alleviates the burden of saving and > > recovering a large register set before and after the call in the > > caller." > > > > [1] https://clang.llvm.org/docs/AttributeReference.html#preserve-most > > You dropped the interesting part: > > | If the arguments are passed in callee-saved registers, then they will > | be preserved by the callee across the call. This doesn=E2=80=99t apply = for > | values returned in callee-saved registers. > | > | =C2=B7 On X86-64 the callee preserves all general purpose registers, = except > | for R11. R11 can be used as a scratch register. Floating-point > | registers (XMMs/YMMs) are not preserved and need to be saved by the > | caller. > | > | =C2=B7 On AArch64 the callee preserve all general purpose registers, = except > | X0-X8 and X16-X18. > > Ideally, this would be documented in the respective psABI supplement. > I filled in some gaps and filed: > > Document the ABI for __preserve_most__ function calls > > > Doesn't this change impact the kernel module ABI? > > I would really expect a check here > > > +#if __has_attribute(__preserve_most__) > > +# define __preserve_most notrace __attribute__((__preserve_most__)) > > +#else > > +# define __preserve_most > > +#endif > > that this is not a compilation for a module. Otherwise modules built > with a compiler with __preserve_most__ attribute support are > incompatible with kernels built with a compiler without that attribute. Surely the Linux kernel has a stable ABI for modules right? Nah. https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst > > Thanks, > Florian > --=20 Thanks, ~Nick Desaulniers