[llvm] r211272 - Emit DWARF3 call frame information when DWARF3+ debug info is requested

Dimitry Andric dimitry at andric.com
Mon Dec 8 12:56:01 PST 2014


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/7e420d39/attachment.sig>


More information about the llvm-commits mailing list