This ability was implicitly removed when debug information got its own specialized meta-data nodes.
Details
Diff Detail
Event Timeline
include/llvm-c/Core.h | ||
---|---|---|
2790 | Would not it be better to name it LLVMCreateDILocation? |
include/llvm-c/Core.h | ||
---|---|---|
2790 | I was trying to match the set and get functions below. |
I'd be really surprised if this debug information worked. To make it work you need DISubprogram metadata which I don't think we want to put in the C API right now - at least not without serious stability caveats.
@echristo What about exposing the bare key-value metadata interface? It itself can be stable, and frontends could use it before anything more specific is stabilized.
@echristo Indeed this doesn't quite work: the generated bitcode is parsable, but invalid, because a DIScope cannot be generated. I was planning to expose DIBuilder as a follow up patch, which should resolve this, but given your comment, you think this is not the right time to do this?
Various things here :
- Typically, there is a LOT of DILoc generated in any non toy module. Wrapping them all in a Value is going to be VERY wasteful. I would vote to add a LLVMMetadataRef type and use it.
- There is no need to create a new C test for that IMO. The echo test should be extended and a module with lcoation information should be fed to it.
- How is the scope created using that API ? If the plan is to use the old way to scope instead of DIScope, then I'm not sure where this is going. This allow to mix the old debug API with the new one, while not being able to get the largest benefit in the name a reduced resource requirement.
On a side note I have a patch that wrap the whole DIBuilder thing in the C API, that i did not submitted yet as testing was lacking.
How is the scope created using that API ?
"I was planning to expose DIBuilder as a follow up patch"
Sorry, missed that bit. OK, let's discuss about how to proceed with this, as it obviously has an impact on this patch.
It seems to me that mapping the new DI API is a good opportunity to introduce LLVMMetadataRef and the MD class hierarchy. Wrapping everything in MetadataAsValue is going to create a tremendous amount of waste. I submitted D19088 , which isn't a a state where it is ready to be merged, but that should help the discussion here.
Would not it be better to name it LLVMCreateDILocation?
This way other methods from the DI family can be imported consistently.
Just a side note though :)