<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7226.0">
<TITLE>can bc/asm carry enough type info for C/C++ compiler/interpreter?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>On Mon, 25 Apr 2005, Misha Brukman wrote:<BR>
>> But since llvm's type system is meant to be lang indep the best we can<BR>
>> do is to make debugging info descriptive enough for future<BR>
>> compilations, is this correct?<BR>
<BR>
> That sounds about right. Another issue is that currently, aggressive<BR>
> optimizations change the code substantially and if there were increased<BR>
> debug information (which would be nice), they would have to be checked<BR>
> and/or modified to be more conservative and respect the memory layout of<BR>
> structures, etc.<BR>
<BR>
>> It would be nice to make bc files optionally carry type info useful<BR>
>> for another compile pass (today bc files are only useful for linking).<BR>
<BR>
> I recon that would be a requirement to a fully-functional llvm-db<BR>
> (debugger) so yes, it would be nice. Patches are accepted. :)<BR>
<BR>
Misha, this would be a requirement on the debugging info as well as a requirement<BR>
on the C++ frontend. The cfe now needs to parse and type check both .h.cxx and the<BR>
debugging info in .bc files. In the short term it would be fine to have a seperate<BR>
utility to regenerate .h files from "g++ -g3" but eventually cfe should have the<BR>
capability to parse dwarf2 and what not. This shouldn't be hard since cfe is the<BR>
one that generated those debugging info in the first place.<BR>
<BR>
Zee</FONT>
</P>
</BODY>
</HTML>