[cfe-dev] [RFC][analyzer][StdLibraryFunctionsChecker] Parsing signatures?
Gábor Márton via cfe-dev
cfe-dev at lists.llvm.org
Tue Sep 22 06:30:01 PDT 2020
Hi,
Here is an example of adding a function summary in
the StdLibraryFunctionsChecker:
// ssize_t recv(int sockfd, void *buf, size_t len, int flags);
addToFunctionSummaryMap(
"recv",
Signature(ArgTypes{IntTy, VoidPtrTy, SizeTy, IntTy},
RetType{Ssize_tTy}),
Summary(NoEvalCall)
.ArgConstraint(ArgumentCondition(0, WithinRange, Range(0,
IntMax)))
.ArgConstraint(BufferSize(/*Buffer=*/ArgNo(1),
/*BufSize=*/ArgNo(2))));
Instead, I'd like to have the following in the future:
addToFunctionSummaryMap(
"recv"
Signature("ssize_t recv(int sockfd, void *buf, size_t len, int
flags);"),
Summary(NoEvalCall)
.ArgConstraint(ArgumentCondition(0, WithinRange, Range(0,
IntMax)))
.ArgConstraint(BufferSize(/*Buffer=*/ArgNo(1),
/*BufSize=*/ArgNo(2))));
Why? This could simplify the type matching code in the Checker extremely.
Besides, whenever we reach up to a point where we can read up summaries
from e.g. YAML files (maybe when we merge with the TaintChecker) then the
user could specify the signatures as they would write that in C/C++, which
seems to be an ultimate convenience.
To achieve this I have to parse the string given to the Signature in the
ASTContext of the TU that is being analyzed. I am considering two options
to develop this:
1) Seems like BodyFarm/ModelInjector does something similar (it reads
function bodies from model files). However, I am not sure if that solution
is flexible enough. Gabor, what do you think, would it make sense to extend
into this direction, could we handle C++ declarations as well? What other
weak points or difficulties do you see?
2) Maybe we could use the parser with a custom ExternalASTSource
implementation that could do the job. Actually, this is how LLDB does it,
the implementation of the ExternalASTSource interface uses the ASTImporter
under the hood. I am not sure if ASTImporter could be used for this, but
maybe some parts of it, we could reuse.
Thanks,
Gabor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200922/cbe2bd6b/attachment.html>
More information about the cfe-dev
mailing list