[llvm-commits] [llvm] r55409 - in /llvm/trunk: include/llvm/Support/DebugInfoBuilder.h lib/VMCore/DebugInfoBuilder.cpp
Talin
viridia at gmail.com
Mon Sep 22 00:14:46 PDT 2008
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
>
>
More information about the llvm-commits
mailing list