[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 11:24:38 PST 2013


>
> Made quite a few changes between the two versions (including adding a test
> case, that's a good start), but didn't explain what the problems you were
> fixing were. What problems were you running into that needed changing?
>
>
> My bad. Since there was no response on the first patch, I assumed people
> will just look at the updated patch.
> The updated patch makes sure we generate the same code when there is only
> one compile unit.
> And the line table will be emitted in the order of CUID.
>
>
That all makes sense.

>
> The MCLineIDs bit seems unwieldy and probably could be done a different
> way.
>
> Any thoughts here?

> 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.

There's really no need to keep track of the first line table for the
> section since the only reason the symbol is ever used is to get the offset
> in cases where a relocation is necessary.
>
> That is true, but it is weird to me if we keep the start symbols for other
> line tables except the first. Let me know whether this should be changed.
>
>
Hmm.. I may have misread but I thought you still had the section symbol and
the line table symbol. If you only have one of those two that's fine. (It's
not really much other than a cleanliness issue anyhow).

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


More information about the llvm-commits mailing list