how to collect information regarding function calls in run time?

[Valdis Kl=?utf-8?Q?=c4=93?=tnieks]

On Tue, 14 May 2019 16:11:51 -0300, Pedro Terra Delboni said:

> I agree that the question alone seems like a weird one, I just assumed
> when I wrote my first email that the explaining the motivation would
> only consume time of the reader.

Asking "what problem are you trying to solve" is a standard question, because
whenever a programmer is saying "I can't get X to do Y", a good 85% of the time
it turns out that  isn't working because using W to do Z is the
already-existing API for what they actually wanted to do....

> The subject I'm working on is Control-Flow Integrity, which instrument
> a code so that each indirect jump (which are usually returns or
> indirect calls) verify if the address they are returning is a valid
> one (so there is a code stub that runs in every function call and
> return).

> The reason I want to count call instructions execution is because the
> function return tied to the most executed call instruction will be the
> one that will cause the greater increase in execution time, so by
> inlining that call we'll be exchanging this cost for the cache impact
> of the code expansion (as the code stub won't exist anymore for this
> call).

I suspect that the vast majority of functions that are *that* heavily used are
either (a) already inlined or (b) too large to inline - for instance, kmalloc
is used heavily, but having separate inlined copies everyplace to avoid the
return statement is going to bloat the code - and even worse, make almost all
the inline copies cache-cold instead of one shared cache-hot chunk of 2K.

And the question we *should* be asking is *not* "is the return address a plausible
one".  It's "is the return address *the one we were called from*".  Checking
whether kmalloc is about to return to a valid call point doesn't tell you much.
Finding out that kmalloc is about to return to one of the 193,358 *other* call
points rather than the one it was actually called from is something big.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20190517/14a7b8e0/attachment.sig>