Re: [PATCH] gcov,x86: Mark GCOV broken for x86

[Peter Zijlstra]

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
head.

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