[llvm] r211272 - Emit DWARF3 call frame information when DWARF3+ debug info is requested
Oliver Stannard
oliver.stannard at arm.com
Tue Dec 9 05:46:59 PST 2014
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
> >>
> >
More information about the llvm-commits
mailing list