[LLVMdev] Compile units in debugging intrinsics / globals

Duncan Sands baldrick at free.fr
Thu Apr 24 00:43:04 PDT 2008


Hi,

> Suppose I have the following source:
> 
> file1:
>   #include "file2"
>   #include "file3"
>   int fn1(void) ...
> 
> file2:
>   int a;
> 
> file3:
>   int fn2(void) ... 
>  
> then fn1, along with all the base types etc appear to be in compile unit
> "file1", the variable a appears to be in compile unit "file2" (and there are
> no basic types in file2, so int is not defined), and fn2 appears to be in
> compile unit "file3". My dwarf records are therefore incorrect, appearing
> something like
> 
> TAG_compile_unit "file1"
>   TAG_subprogram "fn1" ...
>     ...
>   TAG_base_type "int" ...
> 
> TAG_compile_init "file2"
>   TAG_variable "a" ...
> 
> TAG_compile_unit "file3"
>   TAG_subprogram "fn2" ...
>     ...
> 
> When, in fact, these compile units "file2" and "file3" are bogus and
> everything should be part of compile_unit "file1".

this is not clear to me.  Isn't it useful to know where to find the
definition of fn2 (in file3)?  I'm pretty sure this is how gcc does
things too: the debugger seems to know that some objects were defined
in header files.

> My question is: can I tell that these three (llvm) compile units are in fact
> components of the single (non-LLVM) compile unit? Or is there some other way
> I should be determining which (non-LLVM) compile unit the records are part
> of?

If you compile file1 into an LLVM module M, then by definition all debug info
in M is for the compile unit file1.  So as long as you're not doing link time
optimization, can't you just grab all debug info from M?

Ciao,

Duncan.




More information about the llvm-dev mailing list