Add thin shims to OCaml interfaces to provide access to DebugLoc info
for Instructions, GlobalVariables and Functions.
Details
- Reviewers
whitequark deadalnix
Diff Detail
- Repository
- rL LLVM
- Build Status
Buildable 30646 Build 30645: arc lint + arc unit
Event Timeline
@whitequark, does this one look mostly straightforward now that the C API is settled?
bindings/ocaml/llvm/llvm_ocaml.c | ||
---|---|---|
873 | Is it legal to use CAMLlocal2 in a conditional like this? |
bindings/ocaml/llvm/llvm_ocaml.c | ||
---|---|---|
873 | 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? |
@whitequark I meant to comment here, I'm not sure how I wound up on that other issue. Reposting for visibility:
Apologies for not bringing this up in the earlier patch, but is there a reason this isn't using/building on the existing DI C bindings we have?
@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.
I agree with @CodaFi, it's better to build on LLVMDILocation* functions here, if for no other reason that they are more robust (and not deprecated).
I've updated this to implement the accessors using the new DI APIs instead of the old wrapped value ones, using the functions added in D60489, D60725 and D60795.
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.
bindings/ocaml/llvm/llvm_ocaml.c | ||
---|---|---|
887 | @CodaFi, is this the filter to find the debug info for a global variable you had in mind? | |
890 | 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. | |
896 | 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. |
@whitequark I could use some feedback on the direction of this patch relative to https://reviews.llvm.org/D60902. This one implements the accessors for the debug locations directly using the newer DI C bindings. On the other hand D60902 begins adding a hierarchy of types to the OCaml bindings, analogous to the DI hierarchy. This patch gives a more direct implementation for the debug location functions, but the other is more extensible if other DI accessors are needed later. Are either of these approaches acceptable? If not, can you explain briefly why so that I can propose an alternative?
Cc @CodaFi for feedback on the API choices, as experience with the C ones could carry over.
Thanks @whitequark , that is very helpful. I'll close this diff in favor of D60902 and continue discussion there.
Is it legal to use CAMLlocal2 in a conditional like this?