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

Manman Ren mren at apple.com
Tue Feb 12 15:13:54 PST 2013


On Feb 12, 2013, at 11:41 AM, David Blaikie <dblaikie at gmail.com> wrote:

> [+mren for visibility]
> 
> On Tue, Feb 12, 2013 at 11:38 AM, Eric Christopher <echristo at gmail.com> wrote:
>> 
>> 
>> On Tue, Feb 12, 2013 at 11:29 AM, David Blaikie <dblaikie at gmail.com> wrote:
>>> 
>>> On Tue, Feb 12, 2013 at 11:14 AM, Eric Christopher <echristo at gmail.com>
>>> wrote:
>>>> 
>>>> 
>>>> 
>>>> On Tue, Feb 12, 2013 at 11:10 AM, Krzysztof Parzyszek
>>>> <kparzysz at codeaurora.org> wrote:
>>>>> 
>>>>> On 2/12/2013 12:51 PM, David Blaikie wrote:
>>>>>> 
>>>>>> 
>>>>>> 174479 & 174785 should've addressed these. Are you still seeing the
>>>>>> issue?
>>>>> 
>>>>> 
>>>>> I can reproduce it this way (on a x86_64 Linux box):
>>>>> 
>>>>> $ /path/to/bld/Release+Asserts/bin/llc
>>>>> stmt-list-multiple-compile-units.ll
>>>>> $ as stmt-list-multiple-compile-units.s -o x.o
>>>>> $ nm x.o | grep line_table
>>>>>                 U .Lline_table_start1
>>>>> 
>>>>> 
>>>>> This is with a very fresh LLVM (from today).

If we have multiple compile units, yes, line_table_start1 will be referenced in at_stmt_list of the 2nd compile unit.
And line_table_start1 will not be defined if we do not emit the debug line entries.
The case where we have a single compile unit should work.
The fix for multiple compile units, as I know, is to always emit the debug line entries.
Without emitting the debug line entries, I don't really know how to calculate at_stmt_list for the 2nd compile unit.

Thanks,
Manman 
>>>>> 
>>>> 
>>>> This is the same thing we mentioned with dragonegg I think?
>>> 
>>> I didn't hit this with DragonEgg after r174785 I don't think. My
>>> simple repro passed & DragonEgg against the GDB test suite seemed to
>>> go back to its pre-174445 results.
>>> 
>>> Not sure any of those produce the multiple compile-unit situation.
>> 
>> 
>> They shouldn't, no. But I think this is the same problem I was mentioning.
>> Same thing if you just decide to pass -no-integrated-as.
>> 
>> -eric




More information about the llvm-commits mailing list