A few questions about programming Clang Static Analyzer checkers.

[LuMingYinDetect]

Dear LLVM Project Developers,

I apologize for the interruption. Recently, I encountered some issues during the process of writing Clang Static Analyzer checkers that I have been unable to resolve. Specifically, the test code is as follows:
int custom_malloc(int **ptr, size_t size,struct Person *person) { *ptr = (int *)malloc(size); if (*ptr == NULL) { printf("Error: Memory allocation failed.\n"); } return 1; }
In the checker, I matched the return statement using the checkEndFunction callback. I want to retrieve the SymbolRef and corresponding MemRegion for the function parameter ptr when the program reaches the return statement (in the test code, ptr points to a new memory region). However, I'm not sure which interface to use to obtain the assignment status of the function's parameters within the function at this point.I look forward to your reply!

[llvmbot]

@llvm/issue-subscribers-clang-static-analyzer

Author: None (LuMingYinDetect)

Dear LLVM Project Developers,

I apologize for the interruption. Recently, I encountered some issues during the process of writing Clang Static Analyzer checkers that I have been unable to resolve. Specifically, the test code is as follows:
int custom_malloc(int **ptr, size_t size,struct Person *person) { *ptr = (int *)malloc(size); if (*ptr == NULL) { printf("Error: Memory allocation failed.\n"); } return 1; }
In the checker, I matched the return statement using the checkEndFunction callback. I want to retrieve the SymbolRef and corresponding MemRegion for the function parameter ptr when the program reaches the return statement (in the test code, ptr points to a new memory region). However, I'm not sure which interface to use to obtain the assignment status of the function's parameters within the function at this point.I look forward to your reply!

[steakhal]

I think I'd need more context about what you want to achieve exactly with the Symbol if you had one.
You could hook check::{Pre,Post}Stmt<ReturnStmt>, or keep using checkEndFunction.
The location context (C.getLocationContext()) describes where you are in the abstract machine call stack, so the topmost entry is the call you are about to pop after the ReturnStmt is completely evaluated.
In both of these cases you would need to reconstruct a ParamVarRegion for the current function, that you could later use to "load from", and get you the desired symbol. This is pretty involved, you may be better off using check::PostCall instead. And even if you would do this, the value may no longer present in the Store because it was already garbage collected.

Incheck::PostCall you will have a nice CallEvent object with some accessors to the parameters and return value of the call.

[LuMingYinDetect]

I think I'd need more context about what you want to achieve exactly with the Symbol if you had one. You could hook check::{Pre,Post}Stmt<ReturnStmt>, or keep using checkEndFunction. The location context (C.getLocationContext()) describes where you are in the abstract machine call stack, so the topmost entry is the call you are about to pop after the ReturnStmt is completely evaluated. In both of these cases you would need to reconstruct a ParamVarRegion for the current function, that you could later use to "load from", and get you the desired symbol. This is pretty involved, you may be better off using check::PostCall instead. And even if you would do this, the value may no longer present in the Store because it was already garbage collected.

Incheck::PostCall you will have a nice CallEvent object with some accessors to the parameters and return value of the call.

Thank you for your patient reply! Actually, my idea is as follows: I want to use the Clang Static Analyzer to generate function summary information. During actual development, developers define many custom memory allocation functions. Therefore, I want to use the Clang Static Analyzer engine to check the memory allocation on each path. Specifically, I first modified the exploration function options of the Clang Static Analyzer to only explore the functions I am interested in. Then, I used the memory allocation modeling mechanism from MallocChecker to enable the checker to automatically model memory allocation functions. Since I want to generate function summary information, I would like to know which dynamically allocated memory is assigned to the function parameters when the function exploration is completed. So, my initial idea was to match the checkendfunction callback, where I could check whether each pointer-type parameter in the current function points to dynamically allocated memory (i.e., a MemRegion). As you mentioned, I previously tried using checkpostcall, but since the functions for generating the summaries are all topframefunction, I found that the Clang Static Analyzer does not invoke checkpostcall for top-level functions. Therefore, I am unsure how to solve this problem. In summary, what I want to obtain is: when a function finishes execution (which can be understood as when it returns), which pointer-type parameters of that function point to a dynamically allocated memory region (where MallocChecker allocates dynamic memory by establishing a symbol). Could you please guide me on how to implement this in code? I look forward to your response!
Taking the following code example as an illustration, I want to generate a function summary for the custom_malloc function, which allocates dynamic memory. In the custom_malloc function, the function parameter ptr allocates a dynamic memory region via the malloc function. I want to check, at the return statement, each pointer-type parameter of custom_malloc to determine which parameters point to a dynamically allocated memory region.
int custom_malloc(int **ptr, size_t size,struct Person *person) { *ptr = (int *)malloc(size); return 1; }
Thank you again for your help, and I look forward to your reply!

[LuMingYinDetect]

I think I'd need more context about what you want to achieve exactly with the Symbol if you had one. You could hook check::{Pre,Post}Stmt<ReturnStmt>, or keep using checkEndFunction. The location context (C.getLocationContext()) describes where you are in the abstract machine call stack, so the topmost entry is the call you are about to pop after the ReturnStmt is completely evaluated. In both of these cases you would need to reconstruct a ParamVarRegion for the current function, that you could later use to "load from", and get you the desired symbol. This is pretty involved, you may be better off using check::PostCall instead. And even if you would do this, the value may no longer present in the Store because it was already garbage collected.

Incheck::PostCall you will have a nice CallEvent object with some accessors to the parameters and return value of the call.

In addition, regarding what you mentioned about creating a ParamVarRegion, I had tried this earlier, which may stem from my unclear description of the issue (please excuse me if my expression is inappropriate, as English is not my native language). What I actually want to retrieve is not the symbol corresponding to the function arguments at the end of the function execution (which can be addressed by constructing a ParamVarRegion), but the dynamically allocated memory pointed to by pointer-type function arguments (the dynamic memory is created and bound in MallocChecker via the getConjuredHeapSymbolVal function). Therefore, obtaining a ParamVarRegion does not solve this problem (or perhaps I do not have enough knowledge about ParamVarRegion). In any case, simply retrieving the symbol corresponding to the argument does not address my issue; what I need is the dynamically allocated memory pointed to by the argument. Once again, thank you for your selfless help!Could you please give me some advice on this issue?

[steakhal]

Let me first reply to your last comment:

[...] bound in MallocChecker via the getConjuredHeapSymbolVal function. Therefore, obtaining a ParamVarRegion does not solve this problem

The parameter value should be a SymRegion, which holds a binding in the store to the memregion of the heap allocated object, thus something like this: https://godbolt.org/z/65G66ETfY

    { "cluster": "SymRegion{reg_$4<int ** pp>}", "pointer": "0x302c4970", "items": [
      { "kind": "Direct", "offset": 0, "value": "&Element{HeapSymRegion{conj_$3{void *, LC1, S27039, #1}},0 S64b,int}" }
    ]}

Basically, you will need an extra pointer chasing compared to what I said earlier: getSVal(paramRegion) as Memregion, then getSVal(of that region) now this should result in the &Elem{HeapSymRegion{...}}, which basically the pointer to the heap object.

---

If I were you, and forced to use CSA for generating function summaries, then I'd do the following:
First, probably reconsider if CSA is the right tool for this. Probably something that does a more traditional dataflow (with joins/merges) is likely better to describe properties of an program that is satisfied on all paths - unlike with CSA where we only prove properties to each execution paths. This limits how reusable the summaries will be. Anyways, I assume you considered this and you probably choose CSA because that already exists and you wouldn't need to reinvent the wheel.

Second, you already control the analysis entry points, so what we could do is to hook the check::EndAnalysis callback. You would have the whole exploded graph. You would "just" need to construct summaries of that graph. This is where it gets difficult.

Basically, you would want to find the relevant nodes in the graph, look at their constraints and somehow formulate assumptions like this: for all paths where paramX > paramY we return a mallocated pointer.
Remember, the execution graph can get really complicated really quick in presence of nested loops or recursion; and the summation must also work for such cases too. Or at least detect if it's too complicated to begin with and just bail out to not waste computation.

You may guess that I'm a bit skeptical, but I'm also very much interested in making summaries. Maybe this could work for small functions. IDK.

There is a reason why nobody does this...

At this point, it's likely better to apply some dataflow technique that is known to be quicky and scalable, but I can also see the benefits of inferring some correlating branch conditions (where path-sensitive analysis like in CSA) really shines and could be useful for some summaries. Probably, the sweet spot is somewhere inbetween, in general avoiding splitting the paths without joining back, but with "some limited" context allow such splits to happen.

[LuMingYinDetect]

Let me first reply to your last comment:

[...] bound in MallocChecker via the getConjuredHeapSymbolVal function. Therefore, obtaining a ParamVarRegion does not solve this problem

The parameter value should be a SymRegion, which holds a binding in the store to the memregion of the heap allocated object, thus something like this: https://godbolt.org/z/65G66ETfY

    { "cluster": "SymRegion{reg_$4<int ** pp>}", "pointer": "0x302c4970", "items": [
      { "kind": "Direct", "offset": 0, "value": "&Element{HeapSymRegion{conj_$3{void *, LC1, S27039, #1}},0 S64b,int}" }
    ]}

Basically, you will need an extra pointer chasing compared to what I said earlier: getSVal(paramRegion) as Memregion, then getSVal(of that region) now this should result in the &Elem{HeapSymRegion{...}}, which basically the pointer to the heap object.

If I were you, and forced to use CSA for generating function summaries, then I'd do the following: First, probably reconsider if CSA is the right tool for this. Probably something that does a more traditional dataflow (with joins/merges) is likely better to describe properties of an program that is satisfied on all paths - unlike with CSA where we only prove properties to each execution paths. This limits how reusable the summaries will be. Anyways, I assume you considered this and you probably choose CSA because that already exists and you wouldn't need to reinvent the wheel.

Second, you already control the analysis entry points, so what we could do is to hook the check::EndAnalysis callback. You would have the whole exploded graph. You would "just" need to construct summaries of that graph. This is where it gets difficult.

Basically, you would want to find the relevant nodes in the graph, look at their constraints and somehow formulate assumptions like this: for all paths where paramX > paramY we return a mallocated pointer. Remember, the execution graph can get really complicated really quick in presence of nested loops or recursion; and the summation must also work for such cases too. Or at least detect if it's too complicated to begin with and just bail out to not waste computation.

You may guess that I'm a bit skeptical, but I'm also very much interested in making summaries. Maybe this could work for small functions. IDK.

There is a reason why nobody does this...

Thank you very much for your patient explanation. I will follow your advice, try it earnestly, and keep learning.

[steakhal]

Please come back to this thread once you have something/gave up. I'm really curious of your result regardless.

[LuMingYinDetect]

Please come back to this thread once you have something/gave up. I'm really curious of your result regardless.

Thank you for your attention! I will keep you updated on my progress.

[LuMingYinDetect]

Please come back to this thread once you have something/gave up. I'm really curious of your result regardless.

Sorry to bother you again! Today, I made multiple attempts to implement the method you mentioned for obtaining the symbol pointed to by the function arguments. Here is the code I wrote:

void MallocChecker::checkEndFunction(const ReturnStmt *S,
                                     CheckerContext &C) const {
  auto State=C.getState();
  State->dump();
  const FunctionDecl *CurrentFunctionDecl=dyn_cast<FunctionDecl>(C.getStackFrame()->getDecl());
  const LocationContext *LC = C.getLocationContext();
  MemRegionManager &MemMgr = C.getSValBuilder().getRegionManager();
  //Traverse each parameter of the function
  for(int i=0;i<CurrentFunctionDecl->getNumParams();i++){
    //Obtain the declaration corresponding to the function parameter
    const Decl *ParamDecl=CurrentFunctionDecl->getParamDecl(i);
    const ParmVarDecl *MatchedParmVarDecl=dyn_cast<ParmVarDecl>(ParamDecl);
    if(!MatchedParmVarDecl->getType()->isAnyPointerType()){
      continue;
    }
    //Obtain the VarRegion corresponding to the function parameter
    const VarRegion *paramVarRegion=MemMgr.getVarRegion(MatchedParmVarDecl, LC);
    //First layer transformation
    const MemRegion *FirstRegion = State->getSVal(paramVarRegion).getAsRegion();
    //Second layer transformation
    SVal SecondSVal = State->getSVal(FirstRegion);
    SecondSVal.getAsSymbol()->dump();
  }
}

I tried to output the program state using State->dump(), as shown below:

"program_state": {
  "store": { "pointer": "0x564dc7f2e1a8", "items": [
    { "cluster": "GlobalSystemSpaceRegion", "pointer": "0x564dc7f2d460", "items": [
      { "kind": "Default", "offset": 0, "value": "conj_$2{int, LC7, S35983, #1}" }
    ]},
    { "cluster": "SymRegion{conj_$0{int &, LC7, no stmt, #0}}", "pointer": "0x564dc7f2d4f0", "items": [
      { "kind": "Default", "offset": 0, "value": "conj_$1{int, LC7, S35983, #1}" }
    ]}
  ]},
  "environment": null,
  "constraints": null,
  "equivalence_classes": null,
  "disequality_info": null,
  "dynamic_types": null,
  "dynamic_casts": null,
  "checker_messages": null
}

In the above output, conj_$1{int, LC7, S35983, #1} corresponds to the symbol of the allocated memory, and this is the symbol I want to retrieve.I first obtain the current FunctionDecl, and then traverse each function parameter by calling the getNumParams function. For each function parameter, I retrieve the corresponding VarRegion using the getVarRegion method. Finally, I convert the VarRegion to an SVal, then to a MemRegion, and again to an SVal. Finally, I output the information using SVal.getAsSymbol().dump(), and the output is as follows:

reg_$5<int * Element{SymRegion{reg_$4<int ** ptr>},0 S64b,int *}>

This output differs significantly from what I expected. I originally anticipated the output to be conj_$1{int, LC6, S35983, #1}, which would allow me to confirm that the function parameter points to the allocated memory by comparing the symbol (which I had previously stored for the allocated memory). Could you please let me know which step might have gone wrong? Once again, thank you for your help, and I look forward to your reply!