Add thin shims to OCaml interfaces to provide access to DebugLoc info
for Instructions, GlobalVariables and Functions.
No, nice catch! The manual states:
Note that there are a number of existing instances of CAMLlocal in nested blocks in this file. Shall I change them at the same time?
@CodaFi, sorry for the delayed reply, I've been busy with other things.
I've been trawling commits since I originally implemented this, and based on your question I'm guessing that you see a way in which the LLVMGetDebugLoc* functions added in D52210 are (partially) redundant? Is it the case that there is redundancy in the C++ interfaces such that the methods called there can be equivalently expressed in terms of generic metadata and DILocations?
Or are you saying that these additions to the ocaml api are already redundant?
I have investigated trying to use LLVMGetMetadata instead of adding LLVMGetDebugLoc* functions, which is my understanding of @CodaFi's question. To summarize my (perhaps incorrect) understanding, on the one hand LLVMGetMetadata calls Instruction::getMetadata which returns Instruction::DbgLoc, a DILocation, cast to MDNode. On the other hand, LLVMGetDebugLocLine calls Instruction::getDebugLoc, a DILocation, and calls DILocation::getLine, which returns DILocation::SubclassData32. It does not seem possible to access that field using the MDNode api. To access such fields would seem to require exposing the class hierarchy below MDNode in LLVM-C. Does that align with your understanding?
My concern is that we’re building parallel API hierarchies here. The old hat way of wrapping metadata nodes in a value and casting out to an LLVMValueRef makes no sense if we have APIs to manipulate metadata more directly.
LLVMDILocationGetLine, LLVMDILocationGetColumn, LLVMDILocationGetScope should do what you want, and we should be building accessors for file and directory information on top of those bindings instead of the old LLVMValueRef ones.
There is a big RFC point to this diff: instead of these functions, do we want to work toward a point where the OCaml bindings mirror the C ones, by adding the whole DI type hierarchy, none of which is currently present? I guess so, but would like some others' thoughts.
@CodaFi, is this the filter to find the debug info for a global variable you had in mind?
This is the only null check I have not seen fail in practice. It's not a big deal, but I wonder if I am overlooking some reason that guarantees that it is always valid.
My understanding is that this deallocation is safe since the returned var already existed in the context, rather than being copied by LLVMGlobalCopyAllMetadata, but a sanity check would be welcome.