Hello,
We're currently developing a PL/I compiler producing LLVM IR, and in particular debugging information which would eventually allow us to leverage LLDB as a PL/I debugger.
PL/I heavily relies on descriptors of various flavours to describe data at runtime, a principle which is somewhat akin to dope vectors in Fortran. The DWARF specification gives an example of how to describe such a descriptor, and it basically relies on the DW_OP_push_object_address operator within DWARF expressions, and we believe that it would be a promising way to implement what we need.
Currently, the LLVM IR does not support this operator within DIExpressions, and we would thus be interested in adding it (with corresponding support in LLDB further down the line).
Would a patch adding the operator into the DIExpression language, but only supporting DWARF generation at this time and not e.g. CodeView, be accepted in principle? What else would the patch have to provide?
I'm not at all familiar with CodeView, so I can't even be sure the operator would map onto it, and I assume that we want the DIExpression subset to be more or less target independent?
Thanks for any pointers,
Markus Lindström, Compiler Engineer, Raincode Labs
Tel : +32 2 522 06 63 | Mob: +32 473 25 19 60 | E-mail markus@raincode.com
https://be.linkedin.com/in/markuslindstrom
Hello,
We're currently developing a PL/I compiler producing LLVM IR, and in particular debugging information which would eventually allow us to leverage LLDB as a PL/I debugger.
PL/I heavily relies on descriptors of various flavours to describe data at runtime, a principle which is somewhat akin to dope vectors in Fortran. The DWARF specification gives an example of how to describe such a descriptor, and it basically relies on the DW_OP_push_object_address operator within DWARF expressions, and we believe that it would be a promising way to implement what we need.
Currently, the LLVM IR does not support this operator within DIExpressions, and we would thus be interested in adding it (with corresponding support in LLDB further down the line).
Sounds like a good idea. It might be worth posting an example of why you need the new operator to make sure there isn't already a way to represent it before you do all the work of creating a patch.
Would a patch adding the operator into the DIExpression language, but only supporting DWARF generation at this time and not e.g. CodeView, be accepted in principle? What else would the patch have to provide?
I don't see a problem with that. My understanding is that the CodeView backend currently only supports a subset of all DIExpressions anyway, either because the CodeView format is less expressive than DWARF or (in some cases) the implementation isn't complete yet.
I'm not at all familiar with CodeView, so I can't even be sure the operator would map onto it, and I assume that we want the DIExpression subset to be more or less target independent?
If the new operator is the correct, unambiguous way of describing a specific concept, we should use it.
-- adrian