Two options have been added: -finstrument-functions-exclude-function-list and -finstrument-functions-exclude-file-list.
The first can be used to exclude functions by name, and the second can be used to exclude a function by the
file name where its definition occurs. Both options take a comma-separated list of values as their argument. By-name
exclusion is done on the demangled name.
Details
- Reviewers
hans
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I'm not sure why I've been added as a reviewer, as I don't develop or review things within clang...
Usually, you should look at who has recently modified the touched files, or reviewed those same files, and add them as reviewers. Often, it's a good idea to add several people as reviewers at once, since not everybody has the time to review everything. You should also look to see if there's a code owner for the impacted code. There is some documentation on finding reviewers here: https://llvm.org/docs/Phabricator.html#finding-potential-reviewers.
Can you share the motivation for this? There's already an attribute to exclude functions from this instrumentation.
clang/lib/CodeGen/CodeGenFunction.cpp | ||
---|---|---|
526 | Why do we need the new F parameter? Doesn't CurFuncDecl work? | |
556 | This seems a rather imprecise match. What is ExcludedFunction is "foo" and we have a function "football", should it be excluded? Also the description says the demangled name is used (which seemed odd) but I don't see any demangling taking place? |
@jhenderson Thanks for the information, I appreciate it.
@hans Thank you for the comments. I'll be looking to address them later.
@hans However, to answer your question: the user may not be in a position to change the source where the troublesome functions are located, in order to add the attribute.
Addressing review comments.
- Dropped argument to ShouldInstrumentFunction().
- Added file name based exclusion, which had accidentally been left out of previous commit.
- Added demangler.
- Applied git clang-format.
@hans To address your concern about loose matching: I went with this approach because it fit my use-case. Do you think that an exact match would be more appropriate?
I appear to have butchered something in trying to apply a patch. I will revisit and resubmit later when I've straightened things out.
See https://clang.llvm.org/docs/SanitizerSpecialCaseList.html , -fsanitize-ignorelist and *san_ignorelist.txt in the Clang resource directory.
If you can state your motivation, I am happy to implement it as I just modified related code for sanitizers.
Why do we need the new F parameter? Doesn't CurFuncDecl work?