[llvm-commits] [llvm] r55409 - in /llvm/trunk: include/llvm/Support/DebugInfoBuilder.h lib/VMCore/DebugInfoBuilder.cpp

[Talin]

That all sounds good to me. I would welcome a more abstract interface to 
generating debug information.

I would be tempted to take the proposal even a step further. In the 
current system, debugging information is represented using the same data 
structures that are used to build up global constants and variables - in 
other words, the debugging info is "encoded" using non-debugging LLVM IR 
primitives. The proposal moves in the direction of having specialized 
types and data structures that are optimized for representing debug 
information. It might be possible to go even farther, and create 
specialized representations (both in text and binary form) for debugging 
primitives that do not depend on the normal non-debugging data 
structrures, allowing the debug info to be as compact, type-safe, and 
convenient to use as possible.

(I would say more but I am recovering from a wrist injury and typing is 
painful.)

Chris Lattner wrote:
>
> On Aug 26, 2008, at 11:51 PM, Evan Cheng wrote:
>
>> Author: evancheng
>> Date: Wed Aug 27 01:51:14 2008
>> New Revision: 55409
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=55409&view=rev
>> Log:
>> Add DebugInfoBuilder. Patch by Talin!
>
> Hi Talin,
>
> Your DebugInfoBuilder looks very nice.  Have you had a chance to look 
> at this proposal?
> http://nondot.org/sabre/LLVMNotes/EmbeddedMetadata.txt
>
> One piece of it (that is orthogonal from the rest) is the 'Debug Info 
> Construction/Manipulation Helper Classes' section.  I hadn't had a 
> chance to dig into your debug info builder before writing that, but I 
> now see that they are very very related.
>
> Between the two, I think that my proposal would be preferable because 
> it would give better type info, and lend itself to clients that want 
> to walk existing debug info, instead of just creating debug info.  The 
> other advantage of my proposal is that it would insulate clients from 
> changes in the debug info representation: the debug classes could be 
> based on GlobalVariables today, but the implementation could change 
> under the covers to use MDNodes in the future with no or little 
> changes to the clients.
>
> What are your thoughts?  If we converge on this, I'd like to convert 
> clang and llvm-gcc over to use the interface we finalize on (probably 
> post 2.4).
>
> -Chris
>
>