[cfe-dev] Debug Info Generation in Clang.

Cédric Venet cedric.venet at laposte.net
Wed Apr 23 11:53:29 PDT 2008


Hi,

 

I did some (very) little work on this in november, but didn’t had time to
get patch out. Some bit of information you could find interesting:

 

A mail from cfe-dev (response from chris):

 

> I started coding and have a few functionalities working but I hesitate 

> between two possible implementations.

> 

> What I started doing is:

> 

> - Add members and accessor functions to CodeGenModule and 

> CodeGenFuntion.

> - Insert code directly in the code generating function of these class, 

> conditionnaly activated on a flag:

 

I'd suggest adding a new class, e.g. CodeGenDebugInfo that holds the debug
related information.  This is the model that llvm-gcc uses it it's
llvm-convert.cpp and llvm-debug.cpp files.  The nice thing about this is
that you can then do stuff like:

 

void CodeGenFunction::GenerateCode(const FunctionDecl *FD) { [...]

 

  // Create subprogram descriptor.

  if (DebugInfo)

    DebugInfo->CreateSubProgramDesc(...);

 

 

The nice thing about this model is that it keeps the debug info emission
code localized in one file, while making the hooks into it obvious.

 

Another mail, I wrote to llvm (without answer):

 

>From the implementation of DISerialiser, It seems to me I need to keep all
my  debug information object alive until the end of the compilation unit
(until the destruction/last use of the instance of DISerialiser). For
example, I would need to keep all the SubprogramDesc for all the functions
from the translation unit. Have I correctly understood?

 

(the problem is that the map of the serialized data is keyed by the address
of the descriptor. If the descriptor is deleted, a new (and different)
descriptor could take the same address and cause an hard to find bug. As far
As I can see, the data isn’t acceded after being serialized, so if not for
the previous point, it would be safe to delete the descriptor after
use/serialization).

 

This make the lifetime management of the object harder. I had a patch for
changing this behavior, allowing us to delete the descriptor once
serialized, but nobody seemed interested.

 

And attached a  first try to add function definition debug information. It
is out of date and had never been working but you may find a few interesting
thing (I mostly copied a part of llvm gcc) [not llvm::scoped_ptr has been
renamed llvm::OwnedPtr or something like this since then].

 

Regards,

 

Cédric

 

 

De : cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] De la
part de Sanjiv.Gupta at microchip.com
Envoyé : mercredi 23 avril 2008 11:42
À : cfe-dev at cs.uiuc.edu
Objet : [cfe-dev] Debug Info Generation in Clang.

 

Hi,

 

I would like to use Clang front-end for our toolchain.

One feature that we would like to see in Clang is the source level debugging
information generation.

 

What is the latest state of clang debug info generation? Is anything being
done about it?

 

If yes, how can I contribute?

 

If not, I would like to take that up. What would be a good starting point? 

 

 

Thanks,

Sanjiv

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20080423/2289e933/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CodeGenDebugInfo.cpp
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20080423/2289e933/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CodeGenDebugInfo.h
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20080423/2289e933/attachment.h>


More information about the cfe-dev mailing list