[llvm] r203821 - MCDwarf: Refactor line table handling into a single data structure
dblaikie at gmail.com
Thu Mar 13 12:13:09 PDT 2014
On Thu, Mar 13, 2014 at 11:53 AM, Eric Christopher <echristo at gmail.com> wrote:
> On Thu, Mar 13, 2014 at 11:44 AM, Rafael Espíndola
> <rafael.espindola at gmail.com> wrote:
>>> Yep - If that's the/an issue I have two thoughts
>> It is an issue for sure.
>>> 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)
>> That is the simplest and also produces a much smaller output. There
>> was a discussion about it some time ago as a reply to r176605. Greg
>> Clayton in particular seems to think it is important to produce
>> multiple tables.
>>> 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?
>> Not being able to represent in an assembly file the objects we produce
>> is a very fundamental design problem. So yes, I think it is worth it.
>>> 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.
>> We only need to implement it is MC first. With that we can key the
>> behaviour on the integrated-as flag instead of -S versus -c.
>> Eric, btw, you never replied to
>> http://llvm.org/bugs/show_bug.cgi?id=18716#c3. What do you think of
>> the design?
> Sorry, got distracted with other work.
> Yeah, I agree we'll probably need some directive to forward reference
> a symbol that doesn't exist yet in the debug_info section. That's
> pretty gross so I'll give it a thought about other ways around it.
> (Other than, of course, not using .file/.loc directives and just
> emitting the sections by hand which could work as well).
Yeah, I sort of wonder why we don't do that... since we have all the
machinery for it (for use in object emission) anyway. Sure, it'd
create bigger asm files... but I'm not sure it's worth the hassle to
More information about the llvm-commits