[llvm-commits] [PATCH] Dwarf: support for LTO where a single object file can have multiple line tables

Eric Christopher echristo at gmail.com
Wed Jan 30 17:28:25 PST 2013


> Any thoughts here?
>
> I used MCLineIDs for fast look-up, do you have any suggestion on what to
> use here?
>
>
It took me a while, but I see what you're doing. Effectively I think you
can just use a lookup in MCLineDivisionsto see if anything is in the set?
Since the SmallSet is going to be stored in exactly the same way anyhow.
Also since I've not bothered to look are the CU ids dense or sparse? i.e.
0, 1, 2 or in metadata node order (0, 12, 255, 444)?


> The bit with CUID = -1 or CUID == 0 seems confusing, can you explain this
>> a bit? At times -1 seems to be for invalid CUs and at other times the
>> first/only CU?
>>
>> "-1" is the default CUID, when DwarfDebug does not exist.
>> So the first line table will be for CUID 0 when DwarfDebug exists, and
>> will be for CUID -1 when DwarfDebug does not exist.
>>
>>
> This seems a bit confusing. Since, for example, we emit a CU for assembly
> files and so something will always be emitting a CU. I could easily not be
> seeing something though. At worst it really needs some comments.
>
> I added some comments.
> +  // CUID and MCLineTableSymbols are set in DwarfDebug, when DwarfDebug
> does
> +  // not exist, CUID will be -1 and MCLineTableSymbols will be empty.
>
> Updated patch is attached.
>
>
Right. I'm not sure why this division exists. Is there some reason why it's
-1 in the other case that I'm missing?

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130130/cb046da7/attachment.html>


More information about the llvm-commits mailing list