From: Peter Zijlstra <email@example.com> To: Fangrui Song <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com Subject: Re: [PATCH] gcov,x86: Mark GCOV broken for x86 Date: Mon, 14 Jun 2021 21:07:00 +0200 [thread overview] Message-ID: <20210614190700.GF68749@worktop.programming.kicks-ass.net> (raw) In-Reply-To: <firstname.lastname@example.org> 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'.
prev parent 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210614190700.GF68749@worktop.programming.kicks-ass.net \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH] gcov,x86: Mark GCOV broken for x86' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * 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).