llvm dev - May 2015 - [LLVMdev] Questions about DWARF handling (esp. re: file and line data)

Dear LLVM devs,

I'm just working on the LLVM assembler's handling of .file and .line
directives. I've noticed some strange things and am wondering if there is a
reason the code works the way it does.

1. MCContext keeps a map of number -> MCDwarfLineTable called
MCDwarfLineTablesCUMap. However, as far as I can see, the only compilation
unit number which is *ever* used is zero! If this is true, then the map is
not serving any useful purpose.

What was the intention of the CU ID numbers? If multiple .file directives
appear in the asm, each one should open a new "CU", is that not so?

2. Although it appears that each MCDwarfLineTable should be for a single
compilation unit, MCDwarfLineTable has a *vector* called MCDwarfFiles (so
each MCDwarfLineTable can have multiple files).

Although you can have references to multiple files in the same
MCDwarfLineTable, it appears that the only one which is ever used is the
first one! MCDwarfLineTable doesn't do any recordkeeping to remember which
line number data belongs to which file, either.

------------------------

I can go through the code and clean up some of these inconsistencies, but I
need to know how it is *intended* to work. Can someone explain?

Thanks,
Alex Dowad
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150529/17edec7b/attachment.html>

On Fri, May 29, 2015 at 2:17 AM, Alex <alexinbeijing at gmail.com> wrote:
> Dear LLVM devs,
>
> I'm just working on the LLVM assembler's handling of .file and
.line
> directives. I've noticed some strange things and am wondering if there
is a
> reason the code works the way it does.
>
> 1. MCContext keeps a map of number -> MCDwarfLineTable called
> MCDwarfLineTablesCUMap. However, as far as I can see, the only compilation
> unit number which is *ever* used is zero! If this is true, then the map is
> not serving any useful purpose.
>
> What was the intention of the CU ID numbers? If multiple .file directives
> appear in the asm, each one should open a new "CU", is that not
so?
>
> 2. Although it appears that each MCDwarfLineTable should be for a single
> compilation unit, MCDwarfLineTable has a *vector* called MCDwarfFiles (so
> each MCDwarfLineTable can have multiple files).
>
> Although you can have references to multiple files in the same
> MCDwarfLineTable, it appears that the only one which is ever used is the
> first one! MCDwarfLineTable doesn't do any recordkeeping to remember
which
> line number data belongs to which file, either.
>
> ------------------------
>
> I can go through the code and clean up some of these inconsistencies, but
> I need to know how it is *intended* to work. Can someone explain?
>
I /think/ a lot of the complexity you're seeing is there for the non-asm
debug info case (look into how these data structures are used when emitting
debug info for LTO, for example - when the debug info metadata in the IR
describes multiple compile units, multiple files, etc)

>
> Thanks,
> Alex Dowad
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150529/829c7816/attachment.html>

On Fri, May 29, 2015 at 11:55 AM, Alex <alexinbeijing at gmail.com> wrote:
>
> On Fri, May 29, 2015 at 8:46 PM, David Blaikie <dblaikie at
gmail.com> wrote:
>
>>
>> On Fri, May 29, 2015 at 2:17 AM, Alex <alexinbeijing at
gmail.com> wrote:
>>
>>> Dear LLVM devs,
>>>
>>> I'm just working on the LLVM assembler's handling of .file
and .line
>>> directives. I've noticed some strange things and am wondering
if there is a
>>> reason the code works the way it does.
>>>
>>> 1. MCContext keeps a map of number -> MCDwarfLineTable called
>>> MCDwarfLineTablesCUMap. However, as far as I can see, the only
compilation
>>> unit number which is *ever* used is zero! If this is true, then the
map is
>>> not serving any useful purpose.
>>>
>>> What was the intention of the CU ID numbers? If multiple .file
>>> directives appear in the asm, each one should open a new
"CU", is that not
>>> so?
>>>
>>> 2. Although it appears that each MCDwarfLineTable should be for a
single
>>> compilation unit, MCDwarfLineTable has a *vector* called
MCDwarfFiles (so
>>> each MCDwarfLineTable can have multiple files).
>>>
>>> Although you can have references to multiple files in the same
>>> MCDwarfLineTable, it appears that the only one which is ever used
is the
>>> first one! MCDwarfLineTable doesn't do any recordkeeping to
remember which
>>> line number data belongs to which file, either.
>>>
>>> ------------------------
>>>
>>> I can go through the code and clean up some of these
inconsistencies,
>>> but I need to know how it is *intended* to work. Can someone
explain?
>>>
>>
>> I /think/ a lot of the complexity you're seeing is there for the
non-asm
>> debug info case (look into how these data structures are used when
emitting
>> debug info for LTO, for example - when the debug info metadata in the
IR
>> describes multiple compile units, multiple files, etc)
>>
>
> Thanks for the reply! To show you how clueless I am (just started reading
> the source a couple days ago): what is LTO?
>
Link Time Optimization - where we put merge multiple LLVM modules together
and optimize/codegen them together for better optimization opportunities.

In this case, the merged module (the result of merging multiple other
modules) would contain a CU for each of the original modules.

> I guess the dichotomy between CUs and files is for situations where (for
> example) several .c files are compiled into a single .o file, and then
> several such .o files are linked into a single executable?
>
Multiple files in a CU occur commonly due to #includes in C code - a single
CU has entities from multiple files - types defined in headers, subprograms
from inline functions in headers, plus types/functions/etc in the main
source file too.

- David

>
> AD
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150529/b5a4377f/attachment.html>