<p dir="ltr">I won't be at my development machine for a few weeks, so it's probably better to file a PR.</p>
<p dir="ltr">Oliver</p>
<div class="gmail_quote">On 23 Dec 2014 20:17, "Dimitry Andric" <<a href="mailto:dimitry@andric.com">dimitry@andric.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think I have now found the root cause for this issue, and why it is<br>
introduced by r211272.<br>
<br>
GCC has a number of different ways of doing its 3-stage bootstrapping,<br>
as described here: <a href="https://gcc.gnu.org/install/build.html" target="_blank">https://gcc.gnu.org/install/build.html</a> . In<br>
particular, it has a --with-build-config=bootstrap-debug setting for its<br>
configure script, which is described as follows:<br>
<br>
"Verifies that the compiler generates the same executable code, whether<br>
or not it is asked to emit debug information. To this end, this option<br>
builds stage2 host programs without debug information, and uses<br>
contrib/compare-debug to compare them with the stripped stage3 object<br>
files. [...]"<br>
<br>
However, if you do not specify any --with-build-config option, but do<br>
specify --enable-bootstrap, the configure script tries to auto-detect<br>
whether objects generated with and without -g are identical, after<br>
stripping:<br>
<br>
7177 case $BUILD_CONFIG in<br>
7178 bootstrap-debug)<br>
7179 if echo "int f (void) { return 0; }" > conftest.c &&<br>
7180 ${CC} -c conftest.c &&<br>
7181 mv conftest.o conftest.o.g0 &&<br>
7182 ${CC} -c -g conftest.c &&<br>
7183 mv conftest.o conftest.o.g &&<br>
7184 ${srcdir}/contrib/compare-debug conftest.o.g0 conftest.o.g > /dev/null 2>&1; then<br>
7185 :<br>
7186 else<br>
7187 BUILD_CONFIG=<br>
7188 fi<br>
7189 rm -f conftest.c conftest.o conftest.o.g0 conftest.o.g<br>
7190 ;;<br>
7191 esac<br>
<br>
So it compiles a very minimal program with and without the -g flag, and<br>
runs its "compare-debug" script on it. The compare-debug script is<br>
rather convoluted, but basically it returns success or failure,<br>
depending on whether stripped versions of the object files to be<br>
compared are identical.<br>
<br>
Note also, that it uses the "host compiler" (e.g. clang) for this test,<br>
since this is still at the point where there nothing is yet built, not<br>
even a stage 1 gcc.<br>
<br>
In case of clang before r211272, objects compiled with or without -g<br>
are identical after stripping:<br>
<br>
$ cat build-config-test.c<br>
int f (void) { return 0; }<br>
$ ~/obj/llvm-r211271/bin/clang -c build-config-test.c -o test-r211271-without-g.o<br>
$ ~/obj/llvm-r211271/bin/clang -c -g build-config-test.c -o test-r211271-with-g.o<br>
$ strip test-r211271-without-g.o<br>
$ strip test-r211271-with-g.o<br>
$ md5 test-r211271-without-g.o test-r211271-with-g.o<br>
MD5 (test-r211271-without-g.o) = e8d1caf0e37db51c305939993f8c1e36<br>
MD5 (test-r211271-with-g.o) = e8d1caf0e37db51c305939993f8c1e36<br>
<br>
But clang r211272 changes this behavior:<br>
<br>
$ ~/obj/llvm-r211272/bin/clang -c build-config-test.c -o test-r211272-without-g.o<br>
$ ~/obj/llvm-r211272/bin/clang -c -g build-config-test.c -o test-r211272-with-g.o<br>
$ strip test-r211272-without-g.o<br>
$ strip test-r211272-with-g.o<br>
$ md5 test-r211272-without-g.o test-r211272-with-g.o<br>
MD5 (test-r211272-without-g.o) = 1d86d9d6073cfcb6f1228dcca27152cc<br>
MD5 (test-r211272-with-g.o) = 640e2850cf02dfe84340619e3757a49c<br>
<br>
So what is the exact difference between those last two stripped object<br>
files? It is exactly the CIE version emitted in the .eh_frame section:<br>
<br>
$ dwarfdump -v -F test-r211272-without-g.o<br>
<br>
.eh_frame<br>
<br>
fde:<br>
< 0><0x00000020:0x0000002b><><fde offset 0x00000018 length: 0x0000001c><eh aug data len 0x0><br>
0x00000020: <off cfa=08(r7) > <off r16=-8(cfa) ><br>
0x00000021: <off cfa=16(r7) > <off r6=-16(cfa) > <off r16=-8(cfa) ><br>
0x00000024: <off cfa=16(r6) > <off r6=-16(cfa) > <off r16=-8(cfa) ><br>
<br>
cie:<br>
< 0> version 3<br>
cie section offset 0 0x00000000<br>
augmentation zR<br>
code_alignment_factor 1<br>
data_alignment_factor -8<br>
return_address_register 16<br>
eh aug data len 0x1 bytes 0x1b<br>
bytes of initial instructions 7<br>
cie length 20<br>
initial instructions<br>
0 DW_CFA_def_cfa r7 8<br>
3 DW_CFA_offset r16 -8 (1 * -8)<br>
5 DW_CFA_nop<br>
6 DW_CFA_nop<br>
<br>
$ dwarfdump -v -F test-r211272-with-g.o<br>
<br>
.eh_frame<br>
<br>
fde:<br>
< 0><0x00000020:0x0000002b><><fde offset 0x00000018 length: 0x0000001c><eh aug data len 0x0><br>
0x00000020: <off cfa=08(r7) > <off r16=-8(cfa) ><br>
0x00000021: <off cfa=16(r7) > <off r6=-16(cfa) > <off r16=-8(cfa) ><br>
0x00000024: <off cfa=16(r6) > <off r6=-16(cfa) > <off r16=-8(cfa) ><br>
<br>
cie:<br>
< 0> version 1<br>
cie section offset 0 0x00000000<br>
augmentation zR<br>
code_alignment_factor 1<br>
data_alignment_factor -8<br>
return_address_register 16<br>
eh aug data len 0x1 bytes 0x1b<br>
bytes of initial instructions 7<br>
cie length 20<br>
initial instructions<br>
0 DW_CFA_def_cfa r7 8<br>
3 DW_CFA_offset r16 -8 (1 * -8)<br>
5 DW_CFA_nop<br>
6 DW_CFA_nop<br>
<br>
r211272 changes this, at least for platforms where the default DWARF<br>
version is 2 (*BSD, Darwin, Solaris), because it now emits CIE version 3<br>
when -g is not specified on the command line. This is because<br>
DwarfDebug::DwarfDebug() retrieves the DWARF version from the module,<br>
and Module::getDwarfVersion() returns 2 when -g is used, but 4 when -g<br>
is not used.<br>
<br>
It looks like CodeGenModule::Release() only sets the module's "Dwarf<br>
Version" flag, whenever a particular -gdwarf-X option is passed to the<br>
CompilerInstance, though. Maybe Module::getDwarfVersion() should not<br>
return dwarf::DWARF_VERSION unconditionally as 4, for platforms that<br>
default to another version. Or maybe the "Dwarf Version" module flag<br>
should always be set, I don't know what the best solution is.<br>
<br>
Having said all that, is this something to put in a PR, so it can be<br>
tracked better? Or is the fix obvious now?<br>
<br>
-Dimitry<br>
<br>
> On 09 Dec 2014, at 20:59, Dimitry Andric <<a href="mailto:dimitry@andric.com">dimitry@andric.com</a>> wrote:<br>
><br>
> No, this is with the binutils 2.24 port installed, which is normally a<br>
> prerequisite for any of the gcc ports. So intermediate copies of gcc<br>
> will run a separately compiled instance of /usr/local/bin/as for its<br>
> assembler work. During the whole build process, I don't see it<br>
> compiling any .S files explicitly with clang either.<br>
><br>
> One other possibility is that each following stage links in some common<br>
> code (e.g. libiberty) from the first stage, so "bad" stuff in there<br>
> would end up in every stage. But I would find that strange, and rather<br>
> expect gcc to distrust the host compiler and thus recompile everything?<br>
><br>
> Unfortunately I'm not yet familiar enough with the inner workings of<br>
> gcc's bootstrapping process, so I will have to look into it a bit more.<br>
><br>
> -Dimitry<br>
><br>
>> On 09 Dec 2014, at 14:46, Oliver Stannard <<a href="mailto:oliver.stannard@arm.com">oliver.stannard@arm.com</a>> wrote:<br>
>><br>
>> Do you know if the clang assembler is being used for the stage2 and stage3<br>
>> builds? According to <a href="https://gcc.gnu.org/install/build.html#TOC0" target="_blank">https://gcc.gnu.org/install/build.html#TOC0</a>, gas will<br>
>> only be rebuilt at each stage if you have the binutils source alongside the<br>
>> gcc source, and I assume it would use the clang assembler otherwise.<br>
>><br>
>> The only difference I can see in the object files is that the debug info is<br>
>> sorted very slightly differently.<br>
>><br>
>> Oliver<br>
>><br>
>>> -----Original Message-----<br>
>>> From: Dimitry Andric [mailto:<a href="mailto:dimitry@andric.com">dimitry@andric.com</a>]<br>
>>> Sent: 08 December 2014 21:46<br>
>>> To: Oliver Stannard<br>
>>> Cc: Baptiste Daroussin; Gerald Pfeifer; David Chisnall; llvm-commits<br>
>>> Subject: Re: [llvm] r211272 - Emit DWARF3 call frame information when<br>
>>> DWARF3+ debug info is requested<br>
>>><br>
>>> And indeed, with just this diff, the stage comparison also succeeds:<br>
>>><br>
>>> Index: contrib/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp<br>
>>> ===================================================================<br>
>>> --- contrib/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp (revision<br>
>>> 275623)<br>
>>> +++ contrib/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp (working copy)<br>
>>> @@ -210,7 +210,7 @@<br>
>>> DwarfVersion = DwarfVersionNumber ? DwarfVersionNumber<br>
>>> : MMI->getModule()-<br>
>>>> getDwarfVersion();<br>
>>><br>
>>> - Asm->OutStreamer.getContext().setDwarfVersion(DwarfVersion);<br>
>>> + //Asm->OutStreamer.getContext().setDwarfVersion(DwarfVersion);<br>
>>><br>
>>> {<br>
>>> NamedRegionTimer T(DbgTimerName, DWARFGroupName,<br>
>>> TimePassesIsEnabled);<br>
>>><br>
>>><br>
>>> Now, as to why this changes behavior so much, I have no idea... :)<br>
>>><br>
>>> -Dimitry<br>
>>><br>
>>>> On 08 Dec 2014, at 21:56, Dimitry Andric <<a href="mailto:dimitry@andric.com">dimitry@andric.com</a>> wrote:<br>
>>>><br>
>>>> So, with just the first part of the commit reverted, the gcc build<br>
>>>> completes OK, with no stage comparison failures. This comes down to<br>
>>> the<br>
>>>> following diff on 3.5.0 sources:<br>
>>>><br>
>>>> --- a/include/llvm/Support/Dwarf.h<br>
>>>> +++ b/include/llvm/Support/Dwarf.h<br>
>>>> @@ -57,6 +57,7 @@ enum LLVMConstants : uint32_t {<br>
>>>> DW_TAG_user_base = 0x1000, // Recommended base for user tags.<br>
>>>><br>
>>>> DWARF_VERSION = 4, // Default dwarf version we output.<br>
>>>> + DW_CIE_VERSION = 1, // Common frame information version.<br>
>>>> DW_PUBTYPES_VERSION = 2, // Section version number for<br>
>>> .debug_pubtypes.<br>
>>>> DW_PUBNAMES_VERSION = 2, // Section version number for<br>
>>> .debug_pubnames.<br>
>>>> DW_ARANGES_VERSION = 2 // Section version number for<br>
>>> .debug_aranges.<br>
>>>> --- a/lib/CodeGen/AsmPrinter/DwarfDebug.cpp<br>
>>>> +++ b/lib/CodeGen/AsmPrinter/DwarfDebug.cpp<br>
>>>> @@ -210,8 +210,6 @@ DwarfDebug::DwarfDebug(AsmPrinter *A, Module *M)<br>
>>>> DwarfVersion = DwarfVersionNumber ? DwarfVersionNumber<br>
>>>> : MMI->getModule()-<br>
>>>> getDwarfVersion();<br>
>>>><br>
>>>> - Asm->OutStreamer.getContext().setDwarfVersion(DwarfVersion);<br>
>>>> -<br>
>>>> {<br>
>>>> NamedRegionTimer T(DbgTimerName, DWARFGroupName,<br>
>>> TimePassesIsEnabled);<br>
>>>> beginModule();<br>
>>>> --- a/lib/MC/MCDwarf.cpp<br>
>>>> +++ b/lib/MC/MCDwarf.cpp<br>
>>>> @@ -1358,10 +1358,7 @@ const MCSymbol<br>
>>> &FrameEmitterImpl::EmitCIE(MCObject<br>
>>>><br>
>>>> // Version<br>
>>>> if (verboseAsm) streamer.AddComment("DW_CIE_VERSION");<br>
>>>> - // For DWARF2, we use CIE version 1<br>
>>>> - // For DWARF3+, we use CIE version 3<br>
>>>> - uint8_t CIEVersion = context.getDwarfVersion() <= 2 ? 1 : 3;<br>
>>>> - streamer.EmitIntValue(CIEVersion, 1);<br>
>>>> + streamer.EmitIntValue(dwarf::DW_CIE_VERSION, 1);<br>
>>>><br>
>>>> // Augmentation String<br>
>>>> SmallString<8> Augmentation;<br>
>>>> @@ -1389,7 +1386,7 @@ const MCSymbol<br>
>>> &FrameEmitterImpl::EmitCIE(MCObject<br>
>>>><br>
>>>> // Return Address Register<br>
>>>> if (verboseAsm) streamer.AddComment("CIE Return Address Column");<br>
>>>> - if (CIEVersion == 1) {<br>
>>>> + if (context.getDwarfVersion() <= 2) {<br>
>>>> assert(MRI->getRARegister() <= 255 &&<br>
>>>> "DWARF 2 encodes return_address_register in one byte");<br>
>>>> streamer.EmitIntValue(MRI->getDwarfRegNum(MRI->getRARegister(),<br>
>>> true), 1);<br>
>>>><br>
>>>> I suspect the crucial part is the deletion of the setDwarfVersion()<br>
>>> call<br>
>>>> in DwarfDebug::DwarfDebug().<br>
>>>><br>
>>>> Btw, please note that FreeBSD still defaults to emitting DWARF2. (We<br>
>>>> initially went with the new default of DWARF4, but after much<br>
>>> grumbling<br>
>>>> that was reverted.)<br>
>>>><br>
>>>> -Dimitry<br>
>>>><br>
>>>>> On 08 Dec 2014, at 21:04, Dimitry Andric <<a href="mailto:dimitry@andric.com">dimitry@andric.com</a>> wrote:<br>
>>>>><br>
>>>>> Hi,<br>
>>>>><br>
>>>>> I just did another gcc build, first reverting the second hunk in<br>
>>>>> MCDwarf.cpp. This still leads to the same stage comparison<br>
>>> failures.<br>
>>>>><br>
>>>>> I will now try reverting just the first part of the commit.<br>
>>>>><br>
>>>>> -Dimitry<br>
>>>>><br>
>>>>>> On 08 Dec 2014, at 17:59, Oliver Stannard <<a href="mailto:oliver.stannard@arm.com">oliver.stannard@arm.com</a>><br>
>>> wrote:<br>
>>>>>><br>
>>>>>> The commit in question should really have been two separate<br>
>>> commits: setting<br>
>>>>>> the CIE version correctly, and using a ULEB128 for the return<br>
>>> address<br>
>>>>>> register in DWARF3+. It may be helpful if you could bisect this a<br>
>>> bit<br>
>>>>>> further (reverting the second hunk in MCDwarf.cpp should do it).<br>
>>>>>><br>
>>>>>> Your readelf output shows that the relocations apply to different<br>
>>> places in<br>
>>>>>> the .debug_info sections, is there any difference in the<br>
>>> .debug_info<br>
>>>>>> sections themselves?<br>
>>>>>><br>
>>>>>> Oliver<br>
>>>>>><br>
>>>>>>> -----Original Message-----<br>
>>>>>>> From: Oliver Stannard [mailto:<a href="mailto:oliver.stannard@arm.com">oliver.stannard@arm.com</a>]<br>
>>>>>>> Sent: 08 December 2014 15:47<br>
>>>>>>> To: 'Dimitry Andric'<br>
>>>>>>> Cc: Baptiste Daroussin; Ed Maste; Roman Divacky; Gerald Pfeifer;<br>
>>> David<br>
>>>>>>> Chisnall; llvm-commits<br>
>>>>>>> Subject: RE: [llvm] r211272 - Emit DWARF3 call frame information<br>
>>> when<br>
>>>>>>> DWARF3+ debug info is requested<br>
>>>>>>><br>
>>>>>>> +llvm-commits<br>
>>>>>>><br>
>>>>>>> Hi,<br>
>>>>>>><br>
>>>>>>> I'm not very familiar with GCC's build system, but if I am<br>
>>>>>>> understanding this correctly the comparison failure is between the<br>
>>>>>>> debug info in the state-2 and stage-3 GCC objects. These were<br>
>>> compiled<br>
>>>>>>> with the stage-1 and stage-2 GCCs, so I can't see how the debug<br>
>>> info<br>
>>>>>>> emitted by clang (which would be present in the stage-1 GCC, but<br>
>>> should<br>
>>>>>>> not affect it's execution) could be involved in this comparison.<br>
>>> Have I<br>
>>>>>>> understood this correctly?<br>
>>>>>>><br>
>>>>>>> Oliver<br>
>>>>>>><br>
>>>>>>>> -----Original Message-----<br>
>>>>>>>> From: Dimitry Andric [mailto:<a href="mailto:dim@freebsd.org">dim@freebsd.org</a>]<br>
>>>>>>>> Sent: 07 December 2014 20:21<br>
>>>>>>>> To: Oliver Stannard<br>
>>>>>>>> Cc: Baptiste Daroussin; Ed Maste; Roman Divacky; Gerald Pfeifer;<br>
>>>>>>> David<br>
>>>>>>>> Chisnall<br>
>>>>>>>> Subject: Re: [llvm] r211272 - Emit DWARF3 call frame information<br>
>>> when<br>
>>>>>>>> DWARF3+ debug info is requested<br>
>>>>>>>><br>
>>>>>>>> On 19 Jun 2014, at 17:39, Oliver Stannard<br>
>>> <<a href="mailto:oliver.stannard@arm.com">oliver.stannard@arm.com</a>><br>
>>>>>>>> wrote:<br>
>>>>>>>>><br>
>>>>>>>>> Author: olista01<br>
>>>>>>>>> Date: Thu Jun 19 10:39:33 2014<br>
>>>>>>>>> New Revision: 211272<br>
>>>>>>>>><br>
>>>>>>>>> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=211272&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=211272&view=rev</a><br>
>>>>>>>>> Log:<br>
>>>>>>>>> Emit DWARF3 call frame information when DWARF3+ debug info is<br>
>>>>>>>> requested<br>
>>>>>>>>><br>
>>>>>>>>> Currently, llvm always emits a DWARF CIE with a version of 1,<br>
>>> even<br>
>>>>>>>> when emitting<br>
>>>>>>>>> DWARF 3 or 4, which both support CIE version 3. This patch makes<br>
>>> it<br>
>>>>>>>> emit the<br>
>>>>>>>>> newer CIE version when we are emitting DWARF 3 or 4. This will<br>
>>> not<br>
>>>>>>>> reduce<br>
>>>>>>>>> compatibility, as we already emit other DWARF3/4 features, and<br>
>>> is<br>
>>>>>>>> worth doing as<br>
>>>>>>>>> the DWARF3 spec removed some ambiguities in the interpretation<br>
>>> of<br>
>>>>>>>> call frame<br>
>>>>>>>>> information.<br>
>>>>>>>>><br>
>>>>>>>>> It also fixes a minor bug where the "return address" field of<br>
>>> the<br>
>>>>>>> CIE<br>
>>>>>>>> was<br>
>>>>>>>>> encoded as a ULEB128, which is only valid when the CIE version<br>
>>> is<br>
>>>>>>> 3.<br>
>>>>>>>> There are<br>
>>>>>>>>> no test changes for this, because (as far as I can tell) none of<br>
>>>>>>> the<br>
>>>>>>>> platforms<br>
>>>>>>>>> that we test have a return address register with a DWARF<br>
>>> register<br>
>>>>>>>> number >127.<br>
>>>>>>>><br>
>>>>>>>> Hi Oliver,<br>
>>>>>>>><br>
>>>>>>>> After a lot of experimentation, I think I found that this<br>
>>> particular<br>
>>>>>>>> commit causes some trouble when building relatively new versions<br>
>>> of<br>
>>>>>>> gcc<br>
>>>>>>>> with clang.<br>
>>>>>>>><br>
>>>>>>>> I'm currently working on importing clang 3.5.0 into FreeBSD 11.0-<br>
>>>>>>>> CURRENT. While doing several tests, I noticed that some of the<br>
>>> gcc<br>
>>>>>>>> ports,<br>
>>>>>>>> lang/gcc48 and lang/gcc49, failed to build due to a bootstrap<br>
>>>>>>>> comparison failure. For example, lang/gcc48 failed with:<br>
>>>>>>>><br>
>>>>>>>> [...]<br>
>>>>>>>> gmake[5]: Leaving directory<br>
>>>>>>>> '/usr/work/share/dim/ports/lang/gcc48/work/build'<br>
>>>>>>>> Comparing stages 2 and 3<br>
>>>>>>>> warning: gcc/cc1-checksum.o differs<br>
>>>>>>>> warning: gcc/cc1obj-checksum.o differs<br>
>>>>>>>> warning: gcc/cc1plus-checksum.o differs<br>
>>>>>>>> Bootstrap comparison failure!<br>
>>>>>>>> gcc/cfg.o differs<br>
>>>>>>>> gcc/coverage.o differs<br>
>>>>>>>> gcc/asan.o differs<br>
>>>>>>>> gcc/tree-ssa-threadupdate.o differs<br>
>>>>>>>> gcc/valtrack.o differs<br>
>>>>>>>> Makefile:18939: recipe for target 'compare' failed<br>
>>>>>>>><br>
>>>>>>>> If I look at the differing object files, I can see some<br>
>>> differences<br>
>>>>>>> in<br>
>>>>>>>> the .rela.debug_info sections. For example, if I use "readelf -<br>
>>> a" to<br>
>>>>>>>> dump gcc/cfg.o, and compare the stage 2 and stage 3 versions, the<br>
>>>>>>> diff<br>
>>>>>>>> boils down to:<br>
>>>>>>>><br>
>>>>>>>> Relocation section '.rela.debug_info' at offset 0x34ca0 contains<br>
>>> 5228<br>
>>>>>>>> entries:<br>
>>>>>>>> Offset Info Type Symbol's<br>
>>>>>>>> Value Symbol's Name + Addend<br>
>>>>>>>> [...]<br>
>>>>>>>> 4382,4391c4382,4391<br>
>>>>>>>> < 000000000000a4f0 0000003c0000000a R_X86_64_32<br>
>>>>>>>> 0000000000000000 .debug_str + bfad<br>
>>>>>>>> < 000000000000a4fc 0000003c0000000a R_X86_64_32<br>
>>>>>>>> 0000000000000000 .debug_str + 59ab<br>
>>>>>>>> < 000000000000a502 0000003c0000000a R_X86_64_32<br>
>>>>>>>> 0000000000000000 .debug_str + f9c1<br>
>>>>>>>> < 000000000000a515 0000003c0000000a R_X86_64_32<br>
>>>>>>>> 0000000000000000 .debug_str + 85bf<br>
>>>>>>>> < 000000000000a51b 0000003c0000000a R_X86_64_32<br>
>>>>>>>> 0000000000000000 .debug_str + 1096<br>
>>>>>>>> < 000000000000a52e 0000003c0000000a R_X86_64_32<br>
>>>>>>>> 0000000000000000 .debug_str + b30<br>
>>>>>>>> < 000000000000a534 0000003c0000000a R_X86_64_32<br>
>>>>>>>> 0000000000000000 .debug_str + 5ab4<br>
>>>>>>>> < 000000000000a543 0000003c0000000a R_X86_64_32<br>
>>>>>>>> 0000000000000000 .debug_str + 417e<br>
>>>>>>>> < 000000000000a549 0000003c0000000a R_X86_64_32<br>
>>>>>>>> 0000000000000000 .debug_str + 2217<br>
>>>>>>>> < 000000000000a558 0000003c0000000a R_X86_64_32<br>
>>>>>>>> 0000000000000000 .debug_str + ce88<br>
>>>>>>>> ---<br>
>>>>>>>>> 000000000000a4ea 0000003c0000000a R_X86_64_32<br>
>>>>>>>> 0000000000000000 .debug_str + bfad<br>
>>>>>>>>> 000000000000a4f6 0000003c0000000a R_X86_64_32<br>
>>>>>>>> 0000000000000000 .debug_str + 59ab<br>
>>>>>>>>> 000000000000a4fc 0000003c0000000a R_X86_64_32<br>
>>>>>>>> 0000000000000000 .debug_str + f9c1<br>
>>>>>>>>> 000000000000a50f 0000003c0000000a R_X86_64_32<br>
>>>>>>>> 0000000000000000 .debug_str + 85bf<br>
>>>>>>>>> 000000000000a515 0000003c0000000a R_X86_64_32<br>
>>>>>>>> 0000000000000000 .debug_str + 1096<br>
>>>>>>>>> 000000000000a528 0000003c0000000a R_X86_64_32<br>
>>>>>>>> 0000000000000000 .debug_str + b30<br>
>>>>>>>>> 000000000000a52e 0000003c0000000a R_X86_64_32<br>
>>>>>>>> 0000000000000000 .debug_str + 5ab4<br>
>>>>>>>>> 000000000000a53d 0000003c0000000a R_X86_64_32<br>
>>>>>>>> 0000000000000000 .debug_str + 417e<br>
>>>>>>>>> 000000000000a543 0000003c0000000a R_X86_64_32<br>
>>>>>>>> 0000000000000000 .debug_str + 2217<br>
>>>>>>>>> 000000000000a552 0000003c0000000a R_X86_64_32<br>
>>>>>>>> 0000000000000000 .debug_str + ce88<br>
>>>>>>>><br>
>>>>>>>> So for just a few of the debug strings, the offsets are slightly<br>
>>>>>>>> different. Something similar also happens for the other .o<br>
>>> files.<br>
>>>>>>>><br>
>>>>>>>> To find the cause of this problem, which does not occur with<br>
>>> clang<br>
>>>>>>>> 3.4.1, I bisected llvm/clang trunk between the branch points for<br>
>>> 3.4<br>
>>>>>>>> and 3.5, and I arrived at your commit r211272, which appears to<br>
>>> cause<br>
>>>>>>>> it.<br>
>>>>>>>><br>
>>>>>>>> Do you have any idea if there might be a bug in this commit? I<br>
>>> know<br>
>>>>>>> it<br>
>>>>>>>> is probably very hard to say, but I'm rather at a loss for the<br>
>>> real<br>
>>>>>>>> explanation...<br>
>>>>>>>><br>
>>>>>>>> -Dimitry<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> llvm-commits mailing list<br>
>>>>>> <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
>>>>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
>>>>><br>
>>>><br>
>><br>
>><br>
>><br>
>><br>
><br>
> _______________________________________________<br>
> llvm-commits mailing list<br>
> <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div>