This is an archive of the discontinued LLVM Phabricator instance.

[OCaml] Add OCaml APIs to access DebugLoc info
AbandonedPublic

Authored by jberdine on Sep 18 2018, 9:20 AM.

Details

Summary

Add thin shims to OCaml interfaces to provide access to DebugLoc info
for Instructions, GlobalVariables and Functions.

Diff Detail

Event Timeline

jberdine created this revision.Sep 18 2018, 9:20 AM
jberdine updated this revision to Diff 169085.Oct 10 2018, 1:51 PM

update re string option

@whitequark, does this one look mostly straightforward now that the C API is settled?

whitequark added inline comments.Oct 28 2018, 11:57 PM
bindings/ocaml/llvm/llvm_ocaml.c
873

Is it legal to use CAMLlocal2 in a conditional like this?

jberdine added inline comments.Oct 29 2018, 3:18 PM
bindings/ocaml/llvm/llvm_ocaml.c
873

No, nice catch! The manual states:

Local variables of type value must be declared with one of the CAMLlocal macros. [...] These macros must be used at the beginning of the function, not in a nested block.

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?

jberdine updated this revision to Diff 171594.Oct 29 2018, 3:32 PM

fix CAMLlocal

jberdine added inline comments.Oct 29 2018, 3:34 PM
bindings/ocaml/llvm/llvm_ocaml.c
873

Other CAMLlocal changes are in D53841 for reference, I'm happy to merge the patches or not either way.

whitequark accepted this revision.Oct 29 2018, 3:52 PM
This revision is now accepted and ready to land.Oct 29 2018, 3:52 PM

@whitequark, could I bother you to commit this for me?

CodaFi added a subscriber: CodaFi.Nov 8 2018, 1:32 PM

@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?

Herald added a project: Restricted Project. · View Herald TranscriptApr 9 2019, 10:40 AM

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 agree, parallel APIs are a no-go. I'll rework shortly.

jberdine updated this revision to Diff 195448.Apr 16 2019, 1:35 PM

update to use new DI APIs

jberdine marked 3 inline comments as done.EditedApr 16 2019, 1:42 PM

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.

jberdine marked 3 inline comments as done.Apr 16 2019, 1:54 PM
jberdine added inline comments.
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.

@jberdine I personally highly prefer the approach in D60902. In general, I believe that the right direction for the OCaml bindings is to evolve towards rich and type-safe accessors.

jberdine abandoned this revision.Oct 11 2019, 6:43 AM

Thanks @whitequark , that is very helpful. I'll close this diff in favor of D60902 and continue discussion there.