[llvm] r211272 - Emit DWARF3 call frame information when DWARF3+ debug info is requested
Dimitry Andric
dimitry at andric.com
Tue Dec 9 11:59:05 PST 2014
No, this is with the binutils 2.24 port installed, which is normally a
prerequisite for any of the gcc ports. So intermediate copies of gcc
will run a separately compiled instance of /usr/local/bin/as for its
assembler work. During the whole build process, I don't see it
compiling any .S files explicitly with clang either.
One other possibility is that each following stage links in some common
code (e.g. libiberty) from the first stage, so "bad" stuff in there
would end up in every stage. But I would find that strange, and rather
expect gcc to distrust the host compiler and thus recompile everything?
Unfortunately I'm not yet familiar enough with the inner workings of
gcc's bootstrapping process, so I will have to look into it a bit more.
-Dimitry
> On 09 Dec 2014, at 14:46, Oliver Stannard <oliver.stannard at arm.com> wrote:
>
> Do you know if the clang assembler is being used for the stage2 and stage3
> builds? According to https://gcc.gnu.org/install/build.html#TOC0, gas will
> only be rebuilt at each stage if you have the binutils source alongside the
> gcc source, and I assume it would use the clang assembler otherwise.
>
> The only difference I can see in the object files is that the debug info is
> sorted very slightly differently.
>
> Oliver
>
>> -----Original Message-----
>> From: Dimitry Andric [mailto:dimitry at andric.com]
>> Sent: 08 December 2014 21:46
>> To: Oliver Stannard
>> Cc: Baptiste Daroussin; Gerald Pfeifer; David Chisnall; llvm-commits
>> Subject: Re: [llvm] r211272 - Emit DWARF3 call frame information when
>> DWARF3+ debug info is requested
>>
>> 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/20141209/18f90ee0/attachment.sig>
More information about the llvm-commits
mailing list