On Sat, 23 Oct 2021 at 00:03, Alexander Lochmann <info@xxxxxxxxxxxxxxxxxxxxx> wrote: > > Maybe Dmitry can shed some light on this. He actually suggested that > optimization. > > - Alex > > On 29.09.21 10:33, Peter Zijlstra wrote: > > On Mon, Sep 27, 2021 at 07:33:40PM +0200, Alexander Lochmann wrote: > >> The existing trace mode stores PCs in execution order. This could lead > >> to a buffer overflow if sufficient amonut of kernel code is executed. > >> Thus, a user might not see all executed PCs. KCOV_MODE_UNIQUE favors > >> completeness over execution order. While ignoring the execution order, > >> it marks a PC as exectued by setting a bit representing that PC. Each > >> bit in the shared buffer represents every fourth byte of the text > >> segment. Since a call instruction on every supported architecture is > >> at least four bytes, it is safe to just store every fourth byte of the > >> text segment. > > > > I'm still trying to wake up, but why are call instruction more important > > than other instructions? Specifically, I'd think any branch instruction > > matters for coverage., > > > > More specifically, x86 can do a tail call with just 2 bytes. Hi Peter, Alex, The calls are important here because we only use PCs that are return PCs from a callback emitted by the compiler. These PCs point to the call of the callback. I don't remember exactly what's the story for tail calls of the callback for both compilers, ideally they should not use tail calls for this call, and I think at least one of them does not use tail calls. But even with tail calls, the callback is emitted into every basic block of code. So it should be (call, some other instructions, call) and at least the first call is not a tail call.
