[LLVMbugs] [Bug 18716] New: [debug info] Need to find a way to represent multiple CUs in a .s file when using .loc

[bugzilla-daemon at llvm.org]

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

            Bug ID: 18716
           Summary: [debug info] Need to find a way to represent multiple
                    CUs in a .s file when using .loc
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: MC
          Assignee: unassignedbugs at nondot.org
          Reporter: rafael.espindola at gmail.com
                CC: echristo at gmail.com, llvmbugs at cs.uiuc.edu,
                    mren at apple.com
    Classification: Unclassified

Using .file and .loc produces assembly files that a quiet a bit more readable.
Unfortunately, using those we are currently not able to represent multiple
compile units in one .s file. This means that the output we produce during LTO
is different if emitting assembly or object files.

There are two problems

1) The .file directive can only be of the forms
  .file NUM PATH
or
  .file NUM DIR PATH

2) The .debug_info section is still printed manually, and it needs an offset
into the .debug_line section for DW_AT_stmt_list. With .loc we only know the
offset of the first compilation unit (it is always 0).

A first idea on how to fix this

* Extend .file to take a compilation unit. It would now also accept

.file NUM DIR CU_NUM

not sure if there is value in accepting ".file NUM CU_NUM".

the meaning of having

.file 42 "bar" "foo" 2
.file 43 "bar foo" 3

is that entry number 42 is for compile unit 2 and entry 43 is for compile unit
3. Omitting the compile unit just means compile unit 0. The numbers passed to
.file are still unique. That allows .loc to remain unchanged.

* For the second problem we probably need a new directive. Something like
.offset_of_cu_in_debug_lines. We would then print

.offset_of_cu_in_debug_lines 0

instead of 

.long   .Lsection_line          # DW_AT_stmt_list

and it would also work for the other compile units.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140203/a3ed2635/attachment.html>