[llvm-commits] [llvm] r61164 - in /llvm/trunk: include/llvm/Analysis/DebugInfo.h include/llvm/CodeGen/MachineModuleInfo.h lib/Analysis/DebugInfo.cpp

[Devang Patel]

On Dec 17, 2008, at 5:28 PM, Chris Lattner wrote:

>
> On Dec 17, 2008, at 2:39 PM, Devang Patel wrote:
>
>> Author: dpatel
>> Date: Wed Dec 17 16:39:29 2008
>> New Revision: 61164
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=61164&view=rev
>> Log:
>>
>> Today the front-ends (llvm-gcc and clang) generate multiple
>> llvm.dbg.compile_units to identify source file for various debug
>> entities. Each llvm.dbg.compile_unit matches one file on the disk.
>> However, the backend only supports one DW_TAG_compile_unit per .o
>> file. The backend selects first compile_unit from the vector to
>> construct DW_TAG_compile_unit entry, which is not correct in all
>> cases.
>>
>> First step to resolve this is, record file name and directory
>> directly in debug info for various debug entities.
>
> Hey Devang,
>
> My understanding is that this just adds two fields to a few
> descriptors.  Instead of bumping the version number for debug info, is
> it possible to just treat structs with insufficient number of elements
> as having them set to empty?  This is what Analysis/DebugInfo does
> already for everything.


I want to use version number to decide:

1) Emit DW_TAG_compile_unit for each DICompileUnit seen vs. Emit just  
one DW_TAG_compile_unit even though multiple DICompileUnit is seen.  
This is for backward compatibility.

2) Use compile_unit to identify source file info. vs. use filename  
field for source file info. In version7, filename field must provide  
source file info. (when required) otherwise we are dealing with  
invalid llvm.dbg value.
-
Devang