From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by sourceware.org (Postfix) with ESMTPS id 951723858D20 for ; Fri, 15 Dec 2023 07:00:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 951723858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 951723858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::12d ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702623639; cv=none; b=u3ryNc6o6El205W9YivT3o6AgNQueRkfrk+VOMvwcMB8yOdWoUgmYKGLqq9qRtCePBfUa1VupNO76cl2X6WJNqOJmH+s75HORzuQjPFjGmph0PZ1CVKcqjba0xms3rhlf5FbnPA+Zk+WPxpwqfgw5IURa1Izue7sph8SA+n5iLI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702623639; c=relaxed/simple; bh=ioBpFvjniQQraDfFsXV0lcFhjE+/ydvUnyNXq1tTFBA=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=xOHsOg6Lt41dF6MkoRYmLrsA3Zd2SdUmSWRK/lVafdLnW6PgXEZ9chwzsaGPqTZ6NhTjy1pTH7N2z6wSnw/tnvcTyRCBC/U/OSpeVnh0oZNVLgG4nC8khMP2WIhs1EeMc+RP6skz/nVdaoOOR3LB+h2XDUvMe6uIdJc6G3lqjGg= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-50c02628291so306027e87.0 for ; Thu, 14 Dec 2023 23:00:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702623636; x=1703228436; darn=gcc.gnu.org; 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=Rklv7r/4jgpQfM6OGJ8lIFK/XM6CjE90J+OUDrfTwjk=; b=iRnDsZlU201Gw69E4hCPw5/TxdBQxXRzOcFiAXs+dAGLXiin+S+gKlagJdhETsx1Fu HMUMDNzd2IkrlatQd4D/KGwGKp25I9VSlF6b4R/+5+yAnIM3MriQx6vqll/tR4vmdzv7 Ebvs6mMkuVH5T+hecRf2XJKKnsp6EpuwxxYxdPrPxGZszvtX/11EEHXW553cMpc+W2fA vKDzLGCxvYjmzorK/AxZ/kEq+cM4Q6yPbOUVTIGZtzz+QmFw9fDTKlNrSpNSu2exwe8P oEw0tTISYMaKLUqZcZpGIqxwIRUqMTvxj8BuCtavMpGpuI06jBa/mE8r0EyT74FISzGk NznQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702623636; x=1703228436; 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=Rklv7r/4jgpQfM6OGJ8lIFK/XM6CjE90J+OUDrfTwjk=; b=qMfxmXTEZrd5tsutLMRModMKOlcOXLcUNaxg+23WUvY8yOYyODi0LyBsNpvDb80FE4 ZonKnKr2dkUfbZCOk5da/UW3GkU9yGbsalUAO1qAVkeOLreKzxXjgS2c8Z/OqsBk6UPS 3RJtwvDI/eeKhItseoKBNUwEXHWBWXFUowwH6plfQz7OPWeIb9jcN+rkVqbsMPfDMaKS rbstn38WKSJFOpYrAnr7H9HqYqiyR0lpzhGErzuLld4v36wztAhqvXkZZcdWMzbX2ZK0 hqaWtWyrrxnPyblVQ8vnvs+vZZn3cniVG7nfcJ7XMuCyjCpDUq0Iuxxla12UsrpMJSlY ZEFg== X-Gm-Message-State: AOJu0YxPrGTuRyNnXvmK7/Kak4JD1NPWeV/gqvGteRMn8dI4mWIQSS8o e3GV5BM88PtoXdZn8DHwWLlZ8agqQ909BFrtMSc= X-Google-Smtp-Source: AGHT+IEjz2D6LrVUfGfYN7w+UBcoZDKvgcSakn9IsAgvvjtDtKzzfiG33tqmKsImJGXB+uIoNNxtfQZ/qgEda6FsFIE= X-Received: by 2002:a05:6512:3b8:b0:50e:1ee7:f599 with SMTP id v24-20020a05651203b800b0050e1ee7f599mr113687lfp.80.1702623635699; Thu, 14 Dec 2023 23:00:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Fri, 15 Dec 2023 08:00:23 +0100 Message-ID: Subject: Re: [PATCH] strub: avoid lto inlining To: Alexandre Oliva Cc: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,WEIRD_QUOTING autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Dec 14, 2023 at 8:53=E2=80=AFPM Alexandre Oliva = wrote: > > > The strub builtins are not suited for cross-unit inlining, they should > only be inlined by the builtin expanders, if at all. While testing on > sparc64, it occurred to me that, if libgcc was built with LTO enabled, > lto1 might inline them, and that would likely break things. So, make > sure they're clearly marked as not inlinable. > > Regstrapped on x86_64-linux-gnu, also testing on sparc-solaris2.11.3. > Ok to install? > > > for libgcc/ChangeLog > > * strub.c (ATTRIBUTE_NOINLINE): New. > (ATTRIBUTE_STRUB_CALLABLE): Add it. > (__strub_dummy_force_no_leaf): Drop it. > --- > libgcc/strub.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/libgcc/strub.c b/libgcc/strub.c > index b0f990d9deebb..5062554d0e1e6 100644 > --- a/libgcc/strub.c > +++ b/libgcc/strub.c > @@ -36,7 +36,12 @@ see the files COPYING3 and COPYING.RUNTIME respectivel= y. If not, see > # define TOPS < > #endif > > -#define ATTRIBUTE_STRUB_CALLABLE __attribute__ ((__strub__ ("callable"))= ) > +/* Make sure these builtins won't be inlined, even with LTO. */ > +#define ATTRIBUTE_NOINLINE \ > + __attribute__ ((__noinline__, __noclone__)) I think __noipa__ is more complete and will make the libgcc functions appea= r as black boxes to callers. OK your or this way. Richard. > + > +#define ATTRIBUTE_STRUB_CALLABLE \ > + __attribute__ ((__strub__ ("callable"))) ATTRIBUTE_NOINLINE > > /* Enter a stack scrubbing context, initializing the watermark to the ca= ller's > stack address. */ > @@ -72,7 +77,6 @@ __strub_update (void **watermark) > /* Dummy function, called to force the caller to not be a leaf function,= so > that it can't use the red zone. */ > static void ATTRIBUTE_STRUB_CALLABLE > -__attribute__ ((__noinline__, __noipa__)) > __strub_dummy_force_no_leaf (void)> { > } > > -- > Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ > Free Software Activist GNU Toolchain Engineer > More tolerance and less prejudice are key for inclusion and diversity > Excluding neuro-others for not behaving ""normal"" is *not* inclusive