[llvm] r203821 - MCDwarf: Refactor line table handling into a single data structure

[David Blaikie]

On Thu, Mar 13, 2014 at 11:30 AM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
>> Thanks for the pointer - Eric and I were chatting about this on the
>> way in this morning & I've some ideas about how this refactoring could
>> lay the foundation for resolving that issue - though I'm not sure I'll
>> get all the way to that in this particular refactoring effort. The
>> debug_line.dwo is my motivating use case for now.
>>
>> (basically the idea is that once we've got line tables as a reusable
>> component it'd be nice to have each (compile or type) unit refer to
>> its line table directly (rather than going through DwarfDebug then to
>> MCStreamer and looking up by CUID each time..) - once that happens, we
>> could build a line table factory function into the MCStreamer - and
>> MCAsmStreamer would just keep returning the same line table while
>> MCObjectStreamer would return a new one each time (and we'd just keep
>> the type unit 'line' table in DwarfDebug directly))
>
> But that would keep the current undesirable behavior that "llc foo.bc
> -o foo.s  && clang -c foo.s" produces one compile unit and "llc
> -filetype=obj foo.bc" produces multiple, no? To fix that we really
> need to find a way to represent multiple compilation units in the
> assembly file.

Yep - If that's the/an issue I have two thoughts

1) *squint very hard* in the direction of the debugger to see whether
this is really valuable (and if it isn't, just produce one line table
shared by all CUs during LTO)

2) Adding a feature to external tools (like gas) doesn't actually fix
our code cleanliness issue - it takes time to ship the new tool and
more time for everyone to upgrade to it before we could turn down the
old behavior entirely - I don't know that the difference is important
enough to worry about that? I mean I suppose if someone cares they
could go & advocate for the feature to be added to gas or any other
assemblers - but for LLVM I'd simply do it the current way (one line
table for all CUs when emitting asm under LTO - which is a pretty
specific set of circumstances to begin with) until the feature was
widely adopted and deployed, then switch, rather than having any
interim period of supporting both forms.

- David