Page MenuHomePhabricator

[bindings/go] Add debug information accessors

Authored by aykevl on Jun 9 2019, 2:53 AM.



Add debug information accessors, as provided in the following patches: (DILocation) metadata kind get/set debug location on a Value (DIScope)

If needed I can split this patch up in multiple pieces if that's easier to review. But this is the subset that is required to read debug information from the IR so it makes testing locally easier.

The API as proposed in this patch is similar to the current Value API, with a single root type and methods that are only valid for certain subclasses. I have considered just implementing generic Line() calls (that are valid on all DINodes that have a line) but the implementation of that got a bit awkward without support from the C API. I've also considered creating generic getters like a Metadata.DebugLoc() that returns a DebugLoc, but there is a mismatch between the Go DI nodes in the LLVM API and the actual DINode class hierarchy, so that's also hard to get right (without being confusing or breaking the API).

Diff Detail


Event Timeline

aykevl created this revision.Jun 9 2019, 2:53 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 9 2019, 2:53 AM
Herald added a subscriber: aprantl. · View Herald Transcript
aykevl marked an inline comment as done.Jun 9 2019, 2:55 AM
aykevl added inline comments.
657 ↗(On Diff #203727)

FileFilename is a bit weird but I used it (instead of just Filename for example) for consistency with the other getters.

CodaFi accepted this revision.Jun 14 2019, 1:48 PM
CodaFi added a subscriber: echristo.


We spoke out of band about the troubles I’m having verifying this locally, but the patch looks good and my limitations shouldn’t hold it back any longer.

@echristo is the Go authority IIRC.

This revision is now accepted and ready to land.Jun 14 2019, 1:48 PM

*points at pcc* :)

@CodaFi thanks for the review! I assume "Accepted" means it can be merged now? (Just checking to be sure).

Unfortunately, it looks like @pcc isn't maintaining the Go bindings anymore. He isn't listed as code owner of the Go bindings but is listed as the code owner of llgo which is the closest I could find.
I am willing to take over code ownership of the Go bindings, at least for now, simply because it looks like I'm using them the most lately. I'm not sure what the procedure or required trust level of such a thing would be but proposing it now anyway :)

This revision was automatically updated to reflect the committed changes.