From: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
To: Pedro Terra Delboni <terra0009@gmail.com>
Cc: kernelnewbies@kernelnewbies.org
Subject: Re: how to collect information regarding function calls in run time?
Date: Fri, 17 May 2019 10:09:48 -0400 [thread overview]
Message-ID: <21382.1558102188@turing-police> (raw)
In-Reply-To: <CAHKDPP_=QNwKLF9rN-sKvG6+NjNgc5-y1tFa+f2K-TeA5r4ocw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1963 bytes --]
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.
[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
next prev parent reply other threads:[~2019-05-17 14:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-03 19:25 how to collect information regarding function calls in run time? Pedro Terra Delboni
2019-04-03 20:15 ` Bharath Vedartham
[not found] ` <CADFy_4FJODA9gT7Enb+eLt-bdJBkkgTmqhhb3AhJhjibgbzD2A@mail.gmail.com>
2019-05-14 13:55 ` Pedro Terra Delboni
2019-05-14 14:05 ` Greg KH
2019-05-14 14:14 ` Pedro Terra Delboni
2019-05-14 17:45 ` Valdis Klētnieks
2019-05-14 19:11 ` Pedro Terra Delboni
2019-05-17 14:09 ` Valdis Klētnieks [this message]
2019-05-17 16:19 ` Pedro Terra Delboni
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=21382.1558102188@turing-police \
--to=valdis.kletnieks@vt.edu \
--cc=kernelnewbies@kernelnewbies.org \
--cc=terra0009@gmail.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).