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

Eric Christopher echristo at gmail.com
Thu Mar 13 12:23:53 PDT 2014


Something worth some thought...

-eric

On Thu, Mar 13, 2014 at 12:13 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 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
> avoid.
>
> - David




More information about the llvm-commits mailing list