[LLVMbugs] [Bug 2258] New: LLVM does not properly handle compile units in debug records

[bugzilla-daemon at cs.uiuc.edu]

http://llvm.org/bugs/show_bug.cgi?id=2258

           Summary: LLVM does not properly handle compile units in debug
                    records
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: richard.smith at antixlabs.com
                CC: llvmbugs at cs.uiuc.edu


This was discussed on the llvmdev mailing list.

The short problem description is that llvm does not distinguish between compile
units and source files in its debug records. Without this distinction it is not
possible to emit dwarf records correctly. This could be resolved if there was
some way of linking the source files common to a compile unit together.

The longer problem description follows:

Consider these two modules which I will compile and link together using gcc:

Module 1 is comprised of one source file:

main.c:
  static int a = 1;
  extern int fn1(void);

  int main (int argc, char **argv) {
    return fn1();
  }

I compile this with the command-line

gcc main.c -g -c -o main.o

Module 2 is comprised of three source files:

file1.c:
  #include "file2.h"
  #include "file3.h"
  int fn1(void) {
    return fn2(a);
  }

file2.h:
  static int a = 2;

file3.h:
  int fn2(int p) {
    return p * 2;
  }

I compile this with the command-line

gcc file1.c -g -c -o file1.o

Finally I link the modules

gcc main.o file1.o -o main

In the non-llvm sense, each of these two modules is a compile unit.

To see the debug records I use:

objdump -W main > objdump.gcc.txt

Looking at this file, I see two compile units as I would expect (plus the C
libraries):

Compilation Unit @ offset 0x1a1:
...
<0><1ac>: Abbrev Number: 1 (DW_TAG_compile_unit)
...
DW_AT_name        : main.c
...
<1><208>: Abbrev Number: 2 (DW_TAG_subprogram)
...
DW_AT_name        : main
...
<1><25a>: Abbrev Number: 6 (DW_TAG_variable)
DW_AT_name        : a

and

Compilation Unit @ offset 0x25b:
...
<0><266>: Abbrev Number: 1 (DW_TAG_compile_unit)
...
DW_AT_name        : file1.c
...
<1><2c3>: Abbrev Number: 2 (DW_TAG_subprogram)
...
DW_AT_name        : fn2
...
<1><2f4>: Abbrev Number: 5 (DW_TAG_subprogram)
...
DW_AT_name        : fn1
...
<1><30d>: Abbrev Number: 6 (DW_TAG_variable)
DW_AT_name        : a

The problem I have is that llvm considers a _source file_ to be a compile
unit. My code generator - a back-end I have built for llc - uses the compile
unit information in the llvm *but an llvm compile unit is indistinct from a
source file*. It is true that I _also_ want to know what source file the
declarations are in, but using the information I have, my code generator
erroneously emits debug records for _four_ different compile units: the one
named "main.c" contains the definition of main and variable a, compile unit
"file1.c" contains the definition of fn1, compile unit "file2.h" contains
the definition of variable a and compile unit "file3.h" contains the
definition of fn2.

The existing dwarf writer used in the existing back-ends makes no attempt to
distinguish compile units and emits all the records within a single unit, which
is also wrong. If I compile my sources as follows:

llvm-gcc -c -g main.c -o main.o
llvm-gcc -c -g file1.c -o file1.o
llvm-ld -disable-opt main.o file1.o -o main
llc main.bc -f -o main -march=x86
gcc main.s -o main
objdump -W main > objdump.llvm.txt

I find that the debug records claim that everything is contained in a single
compile unit named "file1.c". I also note that because both of the compile
units contained variables named a, llvm has only emitted one debug record
for such a variable and no matter where I query the value of it when
debugging I always get given the value of the variable in main.c.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.