Can CodeGraph Identify Callback Functions in C Code?

[zmcrazy]

It seems that codegraph cannot find the C function point callers ...

⚙ codegraph_codegraph_callers [symbol=_gtpv1_u_recv_cb]

 Let me find out what calls _gtpv1_tun_recv_cb and                     
 _gtpv1_tun_recv_eth_cb, and also look for the system receive          
 entry points like epoll, select, recv, read, etc.                     
 </think>                                                              
                                                                       
 ⚙ codegraph_codegraph_callers [symbol=_gtpv1_tun_recv_cb]             
                                                                       
 The codegraph doesn't have information about who calls these          
 callbacks - they are likely registered as function pointers. Let      
 me search for where these callbacks are registered or set up.         
 </think>

[wu-yue-yu]

I tried to modify codegraph backend, switch treesitter into a LSP to get better result of static analysis, it can get some function pointer caller like callback.
But for some callback stored in structure, rely on static analysis only will lead to some incorrect results. So I'm trying to add AI semantic analysis fallback to LSP static analysis, and it seems feasible.

[colbymchenry]

Great question — and thanks @wu-yue-yu for the LSP experiment notes. As of #807 (merged, ships in the next release) the answer changes:

What CodeGraph now does — the registration side. A function used as a value produces a reference edge from the registration site to the function, in C and all other supported languages:

• passed as an argument: register_handler(my_recv_cb), signal(SIGINT, handler), qsort(…, compare)
• assigned to a function pointer: ops->recv_cb = my_recv_cb, &my_recv_cb
• struct initializers and function tables: { .recv_cb = my_recv_cb }, static cb_t table[] = { cb_a, cb_b } — including cross-file command tables (redis-style { "get", getCommand } in server.c with getCommand defined in t_string.c)

So codegraph_callers my_recv_cb now returns direct callers plus every place the callback is wired up, labeled via callback registration, and codegraph_impact includes registration sites in the blast radius — a callback with no direct calls no longer looks dead. Validated on redis: +1,918 edges, a 30/30 random sample all genuine registrations (module command tables, dict-type vtables, qsort comparators, timer callbacks), with zero changes to any existing call edge.

What stays uncovered, deliberately — the dispatch side. Resolving the indirect call (o->recv_cb(arg) → the concrete function stored in that field) needs data-flow through struct fields. As you found with the LSP + AI-fallback experiments, static analysis alone gets struct-stored callbacks wrong — and for CodeGraph a wrong edge is worse than a missing one, since impact results have to stay trustworthy. So we link registrations (deterministic — the name is in the source) and stay silent on dispatch rather than guess. In practice the registration edges cover the agent's actual follow-up question ("where is this callback installed?") in one callers call.

Re-index after upgrading to pick it up (codegraph index -f — codegraph status will also flag the index as stale). Full design + per-language validation record: docs/design/function-ref-capture.md.