[llvm] r211272 - Emit DWARF3 call frame information when DWARF3+ debug info is requested
Dimitry Andric
dimitry at andric.com
Mon Dec 8 12:04:06 PST 2014
Hi,
I just did another gcc build, first reverting the second hunk in
MCDwarf.cpp. This still leads to the same stage comparison failures.
I will now try reverting just the first part of the commit.
-Dimitry
> On 08 Dec 2014, at 17:59, Oliver Stannard <oliver.stannard at arm.com> wrote:
>
> The commit in question should really have been two separate commits: setting
> the CIE version correctly, and using a ULEB128 for the return address
> register in DWARF3+. It may be helpful if you could bisect this a bit
> further (reverting the second hunk in MCDwarf.cpp should do it).
>
> Your readelf output shows that the relocations apply to different places in
> the .debug_info sections, is there any difference in the .debug_info
> sections themselves?
>
> Oliver
>
>> -----Original Message-----
>> From: Oliver Stannard [mailto:oliver.stannard at arm.com]
>> Sent: 08 December 2014 15:47
>> To: 'Dimitry Andric'
>> Cc: Baptiste Daroussin; Ed Maste; Roman Divacky; Gerald Pfeifer; David
>> Chisnall; llvm-commits
>> Subject: RE: [llvm] r211272 - Emit DWARF3 call frame information when
>> DWARF3+ debug info is requested
>>
>> +llvm-commits
>>
>> Hi,
>>
>> I'm not very familiar with GCC's build system, but if I am
>> understanding this correctly the comparison failure is between the
>> debug info in the state-2 and stage-3 GCC objects. These were compiled
>> with the stage-1 and stage-2 GCCs, so I can't see how the debug info
>> emitted by clang (which would be present in the stage-1 GCC, but should
>> not affect it's execution) could be involved in this comparison. Have I
>> understood this correctly?
>>
>> Oliver
>>
>>> -----Original Message-----
>>> From: Dimitry Andric [mailto:dim at freebsd.org]
>>> Sent: 07 December 2014 20:21
>>> To: Oliver Stannard
>>> Cc: Baptiste Daroussin; Ed Maste; Roman Divacky; Gerald Pfeifer;
>> David
>>> Chisnall
>>> Subject: Re: [llvm] r211272 - Emit DWARF3 call frame information when
>>> DWARF3+ debug info is requested
>>>
>>> On 19 Jun 2014, at 17:39, Oliver Stannard <oliver.stannard at arm.com>
>>> wrote:
>>>>
>>>> Author: olista01
>>>> Date: Thu Jun 19 10:39:33 2014
>>>> New Revision: 211272
>>>>
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=211272&view=rev
>>>> Log:
>>>> Emit DWARF3 call frame information when DWARF3+ debug info is
>>> requested
>>>>
>>>> Currently, llvm always emits a DWARF CIE with a version of 1, even
>>> when emitting
>>>> DWARF 3 or 4, which both support CIE version 3. This patch makes it
>>> emit the
>>>> newer CIE version when we are emitting DWARF 3 or 4. This will not
>>> reduce
>>>> compatibility, as we already emit other DWARF3/4 features, and is
>>> worth doing as
>>>> the DWARF3 spec removed some ambiguities in the interpretation of
>>> call frame
>>>> information.
>>>>
>>>> It also fixes a minor bug where the "return address" field of the
>> CIE
>>> was
>>>> encoded as a ULEB128, which is only valid when the CIE version is
>> 3.
>>> There are
>>>> no test changes for this, because (as far as I can tell) none of
>> the
>>> platforms
>>>> that we test have a return address register with a DWARF register
>>> number >127.
>>>
>>> Hi Oliver,
>>>
>>> After a lot of experimentation, I think I found that this particular
>>> commit causes some trouble when building relatively new versions of
>> gcc
>>> with clang.
>>>
>>> I'm currently working on importing clang 3.5.0 into FreeBSD 11.0-
>>> CURRENT. While doing several tests, I noticed that some of the gcc
>>> ports,
>>> lang/gcc48 and lang/gcc49, failed to build due to a bootstrap
>>> comparison failure. For example, lang/gcc48 failed with:
>>>
>>> [...]
>>> gmake[5]: Leaving directory
>>> '/usr/work/share/dim/ports/lang/gcc48/work/build'
>>> Comparing stages 2 and 3
>>> warning: gcc/cc1-checksum.o differs
>>> warning: gcc/cc1obj-checksum.o differs
>>> warning: gcc/cc1plus-checksum.o differs
>>> Bootstrap comparison failure!
>>> gcc/cfg.o differs
>>> gcc/coverage.o differs
>>> gcc/asan.o differs
>>> gcc/tree-ssa-threadupdate.o differs
>>> gcc/valtrack.o differs
>>> Makefile:18939: recipe for target 'compare' failed
>>>
>>> If I look at the differing object files, I can see some differences
>> in
>>> the .rela.debug_info sections. For example, if I use "readelf -a" to
>>> dump gcc/cfg.o, and compare the stage 2 and stage 3 versions, the
>> diff
>>> boils down to:
>>>
>>> Relocation section '.rela.debug_info' at offset 0x34ca0 contains 5228
>>> entries:
>>> Offset Info Type Symbol's
>>> Value Symbol's Name + Addend
>>> [...]
>>> 4382,4391c4382,4391
>>> < 000000000000a4f0 0000003c0000000a R_X86_64_32
>>> 0000000000000000 .debug_str + bfad
>>> < 000000000000a4fc 0000003c0000000a R_X86_64_32
>>> 0000000000000000 .debug_str + 59ab
>>> < 000000000000a502 0000003c0000000a R_X86_64_32
>>> 0000000000000000 .debug_str + f9c1
>>> < 000000000000a515 0000003c0000000a R_X86_64_32
>>> 0000000000000000 .debug_str + 85bf
>>> < 000000000000a51b 0000003c0000000a R_X86_64_32
>>> 0000000000000000 .debug_str + 1096
>>> < 000000000000a52e 0000003c0000000a R_X86_64_32
>>> 0000000000000000 .debug_str + b30
>>> < 000000000000a534 0000003c0000000a R_X86_64_32
>>> 0000000000000000 .debug_str + 5ab4
>>> < 000000000000a543 0000003c0000000a R_X86_64_32
>>> 0000000000000000 .debug_str + 417e
>>> < 000000000000a549 0000003c0000000a R_X86_64_32
>>> 0000000000000000 .debug_str + 2217
>>> < 000000000000a558 0000003c0000000a R_X86_64_32
>>> 0000000000000000 .debug_str + ce88
>>> ---
>>>> 000000000000a4ea 0000003c0000000a R_X86_64_32
>>> 0000000000000000 .debug_str + bfad
>>>> 000000000000a4f6 0000003c0000000a R_X86_64_32
>>> 0000000000000000 .debug_str + 59ab
>>>> 000000000000a4fc 0000003c0000000a R_X86_64_32
>>> 0000000000000000 .debug_str + f9c1
>>>> 000000000000a50f 0000003c0000000a R_X86_64_32
>>> 0000000000000000 .debug_str + 85bf
>>>> 000000000000a515 0000003c0000000a R_X86_64_32
>>> 0000000000000000 .debug_str + 1096
>>>> 000000000000a528 0000003c0000000a R_X86_64_32
>>> 0000000000000000 .debug_str + b30
>>>> 000000000000a52e 0000003c0000000a R_X86_64_32
>>> 0000000000000000 .debug_str + 5ab4
>>>> 000000000000a53d 0000003c0000000a R_X86_64_32
>>> 0000000000000000 .debug_str + 417e
>>>> 000000000000a543 0000003c0000000a R_X86_64_32
>>> 0000000000000000 .debug_str + 2217
>>>> 000000000000a552 0000003c0000000a R_X86_64_32
>>> 0000000000000000 .debug_str + ce88
>>>
>>> So for just a few of the debug strings, the offsets are slightly
>>> different. Something similar also happens for the other .o files.
>>>
>>> To find the cause of this problem, which does not occur with clang
>>> 3.4.1, I bisected llvm/clang trunk between the branch points for 3.4
>>> and 3.5, and I arrived at your commit r211272, which appears to cause
>>> it.
>>>
>>> Do you have any idea if there might be a bug in this commit? I know
>> it
>>> is probably very hard to say, but I'm rather at a loss for the real
>>> explanation...
>>>
>>> -Dimitry
>
>
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141208/9dbd0841/attachment.sig>
More information about the llvm-commits
mailing list