From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 736A33877432; Mon, 21 Jun 2021 19:11:07 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 736A33877432
From: "ndesaulniers at google dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug gcov-profile/80223] RFE: Exclude functions from profile
 instrumentation
Date: Mon, 21 Jun 2021 19:11:07 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: gcov-profile
X-Bugzilla-Version: 7.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: ndesaulniers at google dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: marxin at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-80223-4-s47aevOgp7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-80223-4@http.gcc.gnu.org/bugzilla/>
References: <bug-80223-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jun 2021 19:11:07 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D80223

--- Comment #15 from Nick Desaulniers <ndesaulniers at google dot com> ---
(In reply to Fangrui Song from comment #14)
> Can a no_profile_instrument_function function be inlined into a function
> without the attribute? This may be controversial but I'd argue that it ca=
n.
> GCC no_stack_protector behaves this way. no_profile_instrument_function c=
an
> mean that user does not want profiling when the function is called with i=
ts
> entity, not via another entity.

I respectfully but strongly disagree. It's surprising to developers when th=
ey
ask for no stack protector, or no profiling instrumentation, then get one
anyways.  For long call chains, it's hard for developers to diagnose on the=
ir
own which function they called that missed such function attribute.

This reminds me of "what color is your function?"
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
As suddenly a developer would need to verify for a no_* attributed function
that they only call no_* attributed functions, or add noinline (which is a =
big
hammer to all call sites, and games with aliases that have the noinline
attribute are kind of ridiculous).

It's less surprising to prevent inline substitution upon function attribute
mismatch. Then a developer can self diagnose with -Rpass=3Dinline. Either w=
ay,
some form of diagnostics would be helpful for these kinds of issues, and has
been requested by Android platform developers working on Zygote.

For no_stack_protector in LLVM, I implemented the rules: upon mismatch, pre=
vent
inline substitution unless the user specified always_inline.  This fixed
suspend/resume bugs in x86 Linux kernels when built with LTO.

Though, I'm happy to revisit that behavior in LLVM; we could add

#define noinline_for_lto __attribute__((__noinline__))

then use that in the Linux kernel instead.=