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

Mon Dec 8 08:59:27 PST 2014

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