archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <>
To: Fangrui Song <>
Subject: Re: [PATCH] gcov,x86: Mark GCOV broken for x86
Date: Mon, 14 Jun 2021 21:07:00 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Jun 14, 2021 at 11:31:35AM -0700, Fangrui Song wrote:
> __attribute__((no_instrument_function)) seems specific to
> -finstrument-functions.  Somehow -pg uses it as well. The name may not be
> generic, so it may be odd to exclude various instrumentations (there are a ton)
> under this generic attribute.
> I'd like to understand the definition of notrace and noinstr.

notrace came first; it disallows tracing (fentry/mcount) on specific
functions where tracing is unsafe, like inside the tracer itself.

noinstr is fairly recent, we lifted a whole bunch of code from asm to C
(because it's something that every arch ends up having to do and pretty
much every arch did it wrong, so we're slowly lifting it into arch
neutral code).

We now call into C before the full (kernel) C runtime is properly setup.
Consider it crt0 if you will. But it's sprinkled throughout arch code
and not nicely isolated to a few .c files.

For this we require that noinstr avoids any and all compiler
instrumentation; this really is C as C was intended, portable assembler
style usage (/me runs).

> With value profiling disabled, clang -fprofile-generate/gcc
> -fprofile-arcs don't add function calls. They just increment a counter
> in a writable section.  Why isn't that allowed for noinstr functions?

Because you can get exceptions from memory accesses just fine, which, if
you're inside an exception handler and haven't dealt with recursion
conditions yet, can be fatal.

> I can understand why -fpatchable-function-entry= is excluded:
> -fpatchable-function-entry= causes the section
> __patchable_function_entries and the kernel may change the nops into
> call instructions. And a function call may not be suitable for certain
> functions.  But I don't understand why incrementing a counter should
> be disallowed.

A memory access can generate #PF, #DB, #VE, #VC, #MC from the top of my

Also that's what you do today, GCC emits calls, and those can cause even
more 'fun'.

      reply	other threads:[~2021-06-14 19:07 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-14 10:17 Peter Zijlstra
2021-06-14 10:31 ` Marco Elver
2021-06-14 14:43 ` Peter Oberparleiter
2021-06-18 11:13   ` Peter Zijlstra
2021-06-21 13:53     ` Peter Oberparleiter
2021-06-14 16:05 ` Nick Desaulniers
2021-06-14 16:20   ` Peter Zijlstra
2021-06-14 18:05     ` Nick Desaulniers
2021-06-14 18:20       ` Borislav Petkov
2021-06-14 19:03         ` Nick Desaulniers
2021-06-14 19:28           ` Borislav Petkov
2021-06-14 18:31       ` Fangrui Song
2021-06-14 19:07         ` Peter Zijlstra [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] gcov,x86: Mark GCOV broken for x86' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).