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

Mon Dec 8 11:22:46 PST 2014

Yes, this is exactly the strange thing about this commit.  Clang
compiles stage-1-gcc, stage-1-gcc compiles stage-2-gcc, and finally
stage-2-gcc compiles stage-3-gcc, after which the .o files for stage 2
and 3 are compared (excluding some checksum-containing ones):

[...]
gmake[5]: Leaving directory '/usr/work/share/dim/ports/lang/gcc/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

I would not expect changes in the stage-1-gcc to "trickle through" to
the follow-up stages, but apparently they do.  I tested clang 3.5.0 and
trunk with only r211272 reverted, and those result in gcc builds where
the stage 2 and 3 compare OK.

One possibility is that the debug info emitted by clang for stage-1-gcc
*does* influence its execution somehow, but I don't yet see the cause.
It can also be possible that some of gcc's components, for example the
libiberty parts, are not part of the different stages, and debug
information in there would then trickle through to the final stage.

For the sake of comparison, I have uploaded the differing object files
from an x86_64 build's stage 2 and 3 here:

  http://www.andric.com/freebsd/clang/diffobjs-stage23.tar.gz

-Dimitry

> On 08 Dec 2014, at 16:47, Oliver Stannard <oliver.stannard at arm.com> wrote:
> 
> +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/b7de9390/attachment.sig>