[llvm] r211272 - Emit DWARF3 call frame information when DWARF3+ debug info is requested
Dimitry Andric
dimitry at andric.com
Mon Dec 8 13:45:58 PST 2014
And indeed, with just this diff, the stage comparison also succeeds:
Index: contrib/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
===================================================================
--- contrib/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp (revision 275623)
+++ contrib/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp (working copy)
@@ -210,7 +210,7 @@
DwarfVersion = DwarfVersionNumber ? DwarfVersionNumber
: MMI->getModule()->getDwarfVersion();
- Asm->OutStreamer.getContext().setDwarfVersion(DwarfVersion);
+ //Asm->OutStreamer.getContext().setDwarfVersion(DwarfVersion);
{
NamedRegionTimer T(DbgTimerName, DWARFGroupName, TimePassesIsEnabled);
Now, as to why this changes behavior so much, I have no idea... :)
-Dimitry
> On 08 Dec 2014, at 21:56, Dimitry Andric <dimitry at andric.com> wrote:
>
> So, with just the first part of the commit reverted, the gcc build
> completes OK, with no stage comparison failures. This comes down to the
> following diff on 3.5.0 sources:
>
> --- a/include/llvm/Support/Dwarf.h
> +++ b/include/llvm/Support/Dwarf.h
> @@ -57,6 +57,7 @@ enum LLVMConstants : uint32_t {
> DW_TAG_user_base = 0x1000, // Recommended base for user tags.
>
> DWARF_VERSION = 4, // Default dwarf version we output.
> + DW_CIE_VERSION = 1, // Common frame information version.
> DW_PUBTYPES_VERSION = 2, // Section version number for .debug_pubtypes.
> DW_PUBNAMES_VERSION = 2, // Section version number for .debug_pubnames.
> DW_ARANGES_VERSION = 2 // Section version number for .debug_aranges.
> --- a/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
> +++ b/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
> @@ -210,8 +210,6 @@ DwarfDebug::DwarfDebug(AsmPrinter *A, Module *M)
> DwarfVersion = DwarfVersionNumber ? DwarfVersionNumber
> : MMI->getModule()->getDwarfVersion();
>
> - Asm->OutStreamer.getContext().setDwarfVersion(DwarfVersion);
> -
> {
> NamedRegionTimer T(DbgTimerName, DWARFGroupName, TimePassesIsEnabled);
> beginModule();
> --- a/lib/MC/MCDwarf.cpp
> +++ b/lib/MC/MCDwarf.cpp
> @@ -1358,10 +1358,7 @@ const MCSymbol &FrameEmitterImpl::EmitCIE(MCObject
>
> // Version
> if (verboseAsm) streamer.AddComment("DW_CIE_VERSION");
> - // For DWARF2, we use CIE version 1
> - // For DWARF3+, we use CIE version 3
> - uint8_t CIEVersion = context.getDwarfVersion() <= 2 ? 1 : 3;
> - streamer.EmitIntValue(CIEVersion, 1);
> + streamer.EmitIntValue(dwarf::DW_CIE_VERSION, 1);
>
> // Augmentation String
> SmallString<8> Augmentation;
> @@ -1389,7 +1386,7 @@ const MCSymbol &FrameEmitterImpl::EmitCIE(MCObject
>
> // Return Address Register
> if (verboseAsm) streamer.AddComment("CIE Return Address Column");
> - if (CIEVersion == 1) {
> + if (context.getDwarfVersion() <= 2) {
> assert(MRI->getRARegister() <= 255 &&
> "DWARF 2 encodes return_address_register in one byte");
> streamer.EmitIntValue(MRI->getDwarfRegNum(MRI->getRARegister(), true), 1);
>
> I suspect the crucial part is the deletion of the setDwarfVersion() call
> in DwarfDebug::DwarfDebug().
>
> Btw, please note that FreeBSD still defaults to emitting DWARF2. (We
> initially went with the new default of DWARF4, but after much grumbling
> that was reverted.)
>
> -Dimitry
>
>> On 08 Dec 2014, at 21:04, Dimitry Andric <dimitry at andric.com> wrote:
>>
>> 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/b16b7554/attachment.sig>
More information about the llvm-commits
mailing list