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

[Oliver Stannard]

+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