<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 25, 2016 at 2:56 PM, Vedant Kumar <span dir="ltr"><<a href="mailto:vsk@apple.com" target="_blank">vsk@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You're right that for the instrprof-basic test DataSize is 2 on i386-Darwin (not 3 as it should be).<br>
<br>
I'm not an expert on the standard, but I don't think it mandates the padding. It doesn't seem like this is CodeGen bug, although I'd be happy to have someone else chime in.<br></blockquote><div><br></div><div>The padding is part of the object. What is the value of sizeof(__llvm_profile_data) ? It should be 40.</div><div><br></div><div>David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'm looking into a fix right now.<br>
<span class="HOEnZb"><font color="#888888"><br>
vedant<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
> On Feb 25, 2016, at 12:54 PM, Xinliang David Li <<a href="mailto:davidxl@google.com">davidxl@google.com</a>> wrote:<br>
><br>
> On Thu, Feb 25, 2016 at 12:44 PM, Vedant Kumar <<a href="mailto:vsk@apple.com">vsk@apple.com</a>> wrote:<br>
>> I'm not sure what you mean by object symtab.<br>
><br>
> 40 is the size recorded in object file's symtab (I only checked ELF)<br>
><br>
>> It's true that sizeof(__llvm_profile_data) is 40, but clang generates assembly that looks like:<br>
>><br>
>> .globl _a1 ## @a1<br>
>> .align 3<br>
>> _a1:<br>
>> .space 36<br>
>><br>
>> So that's how the linker knows the object's 'real' size and alignment.<br>
><br>
> Is this a code gen bug? On Linux, the symbol will have an explicit<br>
> '.size 40' directive in the assembly file.<br>
><br>
>><br>
>> I thought the DataSize field in the raw header referred to the number of profile data entries in the profile, and check-profile doesn't seem broken. Have you seen data entries being dropped?<br>
><br>
> The function gets dropped may not be examined in our test. Can you<br>
> check for 32 bit dwarwin, what DataSize is recorded in the header?<br>
><br>
> David<br>
>><br>
>> vedant<br>
>><br>
>><br>
>>> On Feb 25, 2016, at 12:29 PM, Xinliang David Li <<a href="mailto:davidxl@google.com">davidxl@google.com</a>> wrote:<br>
>>><br>
>>> Actually this is still not quite right. The Data object size should<br>
>>> be 40 bytes (in object symtab). I wonder how the linker gets the 36<br>
>>> byte.<br>
>>><br>
>>> Your patch can fix the crash, but the recorded number of Data (aka<br>
>>> DataSize field in the raw header) will still be wrong -- the last<br>
>>> function's data will be dropped.<br>
>>><br>
>>> David<br>
>>><br>
>>> On Tue, Feb 23, 2016 at 12:41 PM, Xinliang David Li <<a href="mailto:davidxl@google.com">davidxl@google.com</a>> wrote:<br>
>>>> Makes sense. The address of the Data is 8 byte aligned, but the size of the<br>
>>>> object is still 36 bytes.<br>
>>>><br>
>>>> David<br>
>>>><br>
>>>> On Tue, Feb 23, 2016 at 12:25 PM, Vedant Kumar <<a href="mailto:vsk@apple.com">vsk@apple.com</a>> wrote:<br>
>>>>><br>
>>>>> I see one more spot where this could be an issue in InstrProfiling.c:<br>
>>>>><br>
>>>>> __llvm_profile_reset_counters()<br>
>>>>> ...<br>
>>>>> - for (DI = DataBegin; DI != DataEnd; ++DI) {<br>
>>>>> + for (DI = DataBegin; DI < DataEnd; ++DI) {<br>
>>>>><br>
>>>>> I can fix this up too.<br>
>>>>><br>
>>>>> vedant<br>
>>>>><br>
>>>>>> On Feb 23, 2016, at 12:22 PM, Vedant Kumar via llvm-commits<br>
>>>>>> <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
>>>>>><br>
>>>>>> Yes, it is linker-related but not a linker bug.<br>
>>>>>><br>
>>>>>> __llvm_profile_data is only required to _start_ at an 8-byte aligned<br>
>>>>>> address.<br>
>>>>>><br>
>>>>>> We shouldn't ever need to access past byte 36 of this structure (on<br>
>>>>>> i386).<br>
>>>>>><br>
>>>>>> In the case of instrprof_basic.c, we have 3 __llvm_profile_data objects.<br>
>>>>>> So the linker allocates 40 + 40 + 36 = 116 bytes.<br>
>>>>>><br>
>>>>>> The iterator in __llvm_profile_gather_value_data walks past the end of<br>
>>>>>> the section. Here is a fix:<br>
>>>>>><br>
>>>>>> - for (I = (__llvm_profile_data *)DataBegin; I != DataEnd; ++I) {<br>
>>>>>> + for (I = (__llvm_profile_data *)DataBegin; I < DataEnd; ++I) {<br>
>>>>>><br>
>>>>>> Is this good to commit?<br>
>>>>>><br>
>>>>>> vedant<br>
>>>>>><br>
>>>>>><br>
>>>>>>> On Feb 23, 2016, at 11:24 AM, Xinliang David Li <<a href="mailto:davidxl@google.com">davidxl@google.com</a>><br>
>>>>>>> wrote:<br>
>>>>>>><br>
>>>>>>> Is the root cause of the issue understood now?<br>
>>>>>>><br>
>>>>>>> thanks,<br>
>>>>>>><br>
>>>>>>> David<br>
>>>>>>><br>
>>>>>>> On Mon, Feb 22, 2016 at 11:55 AM, Xinliang David Li<br>
>>>>>>> <<a href="mailto:davidxl@google.com">davidxl@google.com</a>> wrote:<br>
>>>>>>>> On Mon, Feb 22, 2016 at 11:37 AM, Vedant Kumar <<a href="mailto:vsk@apple.com">vsk@apple.com</a>> wrote:<br>
>>>>>>>>> vsk added a comment.<br>
>>>>>>>>><br>
>>>>>>>>> Hi David,<br>
>>>>>>>>><br>
>>>>>>>>> This commit enables tests on 64-bit Darwin which have apparently been<br>
>>>>>>>>> failing. I now see:<br>
>>>>>>>>><br>
>>>>>>>>> ******************** TEST 'Profile-i386 :: instrprof-basic.c' FAILED<br>
>>>>>>>>> ********************<br>
>>>>>>>>> Script:<br>
>>>>>>>>> --<br>
>>>>>>>>> /Users/vk/Desktop/llvm/Debug+Asserts/./bin/clang -arch i386<br>
>>>>>>>>> -fprofile-instr-generate -o<br>
>>>>>>>>> /Users/vk/Desktop/llvm/build/projects/compiler-rt/test/profile/Profile-i386/Output/instrprof-basic.c.tmp<br>
>>>>>>>>> -O3<br>
>>>>>>>>> /Users/vk/Desktop/llvm/projects/compiler-rt/test/profile/instrprof-basic.c<br>
>>>>>>>>> env<br>
>>>>>>>>> LLVM_PROFILE_FILE=/Users/vk/Desktop/llvm/build/projects/compiler-rt/test/profile/Profile-i386/Output/instrprof-basic.c.tmp.profraw<br>
>>>>>>>>> /Users/vk/Desktop/llvm/build/projects/compiler-rt/test/profile/Profile-i386/Output/instrprof-basic.c.tmp<br>
>>>>>>>>> llvm-profdata merge -o<br>
>>>>>>>>> /Users/vk/Desktop/llvm/build/projects/compiler-rt/test/profile/Profile-i386/Output/instrprof-basic.c.tmp.profdata<br>
>>>>>>>>> /Users/vk/Desktop/llvm/build/projects/compiler-rt/test/profile/Profile-i386/Output/instrprof-basic.c.tmp.profraw<br>
>>>>>>>>> /Users/vk/Desktop/llvm/Debug+Asserts/./bin/clang -arch i386<br>
>>>>>>>>> -fprofile-instr-use=/Users/vk/Desktop/llvm/build/projects/compiler-rt/test/profile/Profile-i386/Output/instrprof-basic.c.tmp.profdata<br>
>>>>>>>>> -o - -S -emit-llvm<br>
>>>>>>>>> /Users/vk/Desktop/llvm/projects/compiler-rt/test/profile/instrprof-basic.c |<br>
>>>>>>>>> FileCheck<br>
>>>>>>>>> /Users/vk/Desktop/llvm/projects/compiler-rt/test/profile/instrprof-basic.c<br>
>>>>>>>>> --<br>
>>>>>>>>> Exit Code: 139<br>
>>>>>>>>><br>
>>>>>>>>> Command Output (stderr):<br>
>>>>>>>>> --<br>
>>>>>>>>><br>
>>>>>>>>> /Users/vk/Desktop/llvm/build/projects/compiler-rt/test/profile/Profile-i386/Output/instrprof-basic.c.script:<br>
>>>>>>>>> line 4: 20417 Segmentation fault: 11 env<br>
>>>>>>>>> LLVM_PROFILE_FILE=/Users/vk/Desktop/llvm/build/projects/compiler-rt/test/profile/Profile-i386/Output/instrprof-basic.c.tmp.profraw<br>
>>>>>>>>> /Users/vk/Desktop/llvm/build/projects/compiler-rt/test/profile/Profile-i386/Output/instrprof-basic.c.tmp<br>
>>>>>>>>><br>
>>>>>>>>> The segmentation fault is in `__llvm_profile_gather_value_data()`.<br>
>>>>>>>>> Accessing `I->Values` dereferences `0x1`:<br>
>>>>>>>>><br>
>>>>>>>>> (lldb) p *I<br>
>>>>>>>>> (__llvm_profile_data) $11 = {<br>
>>>>>>>>> NameRef = 10864<br>
>>>>>>>>> FuncHash = 48378511633216<br>
>>>>>>>>> CounterPtr = 0x00000000<br>
>>>>>>>>> FunctionPointer = 0x0000df1e<br>
>>>>>>>>> Values = 0x00000001<br>
>>>>>>>>> NumCounters = 0<br>
>>>>>>>>> NumValueSites = ([0] = 13723)<br>
>>>>>>>>> }<br>
>>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> Looks like the prof data iterator is returning some garbage entry. For<br>
>>>>>>>> that test, it should have only 3 entries. If it iterates more<br>
>>>>>>>> entries, it is likely a linker bug on darwin.<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>>> There's a second issue with corrupt raw profiles:<br>
>>>>>>>>><br>
>>>>>>>>> ********************<br>
>>>>>>>>> FAIL: Profile-i386 :: instrprof-without-libc.c (39 of 96)<br>
>>>>>>>>> ******************** TEST 'Profile-i386 :: instrprof-without-libc.c'<br>
>>>>>>>>> FAILED ********************<br>
>>>>>>>>> Script:<br>
>>>>>>>>> --<br>
>>>>>>>>> /Users/vk/Desktop/llvm/Debug+Asserts/./bin/clang -arch i386<br>
>>>>>>>>> -fprofile-instr-generate -DCHECK_SYMBOLS -O3 -o<br>
>>>>>>>>> /Users/vk/Desktop/llvm/build/projects/compiler-rt/test/profile/Profile-i386/Output/instrprof-without-libc.c.tmp.symbols<br>
>>>>>>>>> /Users/vk/Desktop/llvm/projects/compiler-rt/test/profile/instrprof-without-libc.c<br>
>>>>>>>>> llvm-nm<br>
>>>>>>>>> /Users/vk/Desktop/llvm/build/projects/compiler-rt/test/profile/Profile-i386/Output/instrprof-without-libc.c.tmp.symbols<br>
>>>>>>>>> | FileCheck<br>
>>>>>>>>> /Users/vk/Desktop/llvm/projects/compiler-rt/test/profile/instrprof-without-libc.c<br>
>>>>>>>>> --check-prefix=CHECK-SYMBOLS<br>
>>>>>>>>> /Users/vk/Desktop/llvm/Debug+Asserts/./bin/clang -arch i386<br>
>>>>>>>>> -fprofile-instr-generate -O3 -o<br>
>>>>>>>>> /Users/vk/Desktop/llvm/build/projects/compiler-rt/test/profile/Profile-i386/Output/instrprof-without-libc.c.tmp<br>
>>>>>>>>> /Users/vk/Desktop/llvm/projects/compiler-rt/test/profile/instrprof-without-libc.c<br>
>>>>>>>>><br>
>>>>>>>>> /Users/vk/Desktop/llvm/build/projects/compiler-rt/test/profile/Profile-i386/Output/instrprof-without-libc.c.tmp<br>
>>>>>>>>> /Users/vk/Desktop/llvm/build/projects/compiler-rt/test/profile/Profile-i386/Output/instrprof-without-libc.c.tmp.profraw<br>
>>>>>>>>> llvm-profdata merge -o<br>
>>>>>>>>> /Users/vk/Desktop/llvm/build/projects/compiler-rt/test/profile/Profile-i386/Output/instrprof-without-libc.c.tmp.profdata<br>
>>>>>>>>> /Users/vk/Desktop/llvm/build/projects/compiler-rt/test/profile/Profile-i386/Output/instrprof-without-libc.c.tmp.profraw<br>
>>>>>>>>> /Users/vk/Desktop/llvm/Debug+Asserts/./bin/clang -arch i386<br>
>>>>>>>>> -fprofile-instr-use=/Users/vk/Desktop/llvm/build/projects/compiler-rt/test/profile/Profile-i386/Output/instrprof-without-libc.c.tmp.profdata<br>
>>>>>>>>> -o - -S -emit-llvm<br>
>>>>>>>>> /Users/vk/Desktop/llvm/projects/compiler-rt/test/profile/instrprof-without-libc.c<br>
>>>>>>>>> | FileCheck<br>
>>>>>>>>> /Users/vk/Desktop/llvm/projects/compiler-rt/test/profile/instrprof-without-libc.c<br>
>>>>>>>>> --<br>
>>>>>>>>> Exit Code: 1<br>
>>>>>>>>><br>
>>>>>>>>> Command Output (stderr):<br>
>>>>>>>>> --<br>
>>>>>>>>> error:<br>
>>>>>>>>> /Users/vk/Desktop/llvm/build/projects/compiler-rt/test/profile/Profile-i386/Output/instrprof-without-libc.c.tmp.profraw:<br>
>>>>>>>>> Invalid instrumentation profile data (file header is corrupt)<br>
>>>>>>>>><br>
>>>>>>>>> This happens because `ProfileSize = 34359738544` (pretty close to 32<br>
>>>>>>>>> GB, which seems wrong):<br>
>>>>>>>>><br>
>>>>>>>>> frame #0: 0x00000001001fa851<br>
>>>>>>>>> llvm-profdata`llvm::RawInstrProfReader<unsigned<br>
>>>>>>>>> int>::readHeader(this=0x0000000100b00000, Header=0x0000000100a00110) + 801<br>
>>>>>>>>> at InstrProfReader.cpp:337<br>
>>>>>>>>> 334<br>
>>>>>>>>> 335 auto *Start = reinterpret_cast<const char<br>
>>>>>>>>> *>(&Header);<br>
>>>>>>>>> 336 if (Start + ProfileSize > DataBuffer->getBufferEnd())<br>
>>>>>>>>> -> 337 return error(instrprof_error::bad_header);<br>
>>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> It is likely that ValueDataSize in the header has bogus value. It is<br>
>>>>>>>> likely related to the bug above -- some bogus function prof data entry<br>
>>>>>>>> gets processed.<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>>> I don't know if this last issue is affected by this commit, but I'm<br>
>>>>>>>>> not sure why these tests are unsupported (they don't seem Linux-specific):<br>
>>>>>>>><br>
>>>>>>>> Looks like i386/darwin was never tested before? This just exposed some<br>
>>>>>>>> latent bug.<br>
>>>>>>>><br>
>>>>>>>> thanks,<br>
>>>>>>>><br>
>>>>>>>> David<br>
>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> UNSUPPORTED: Profile-x86_64 :: Linux/coverage_ctors.cpp (1 of 32)<br>
>>>>>>>>> UNSUPPORTED: Profile-x86_64 :: Linux/coverage_dtor.cpp (2 of 32)<br>
>>>>>>>>> UNSUPPORTED: Profile-x86_64 :: Linux/instrprof-basic.c (3 of 32)<br>
>>>>>>>>> UNSUPPORTED: Profile-x86_64 :: Linux/coverage_test.cpp (4 of 32)<br>
>>>>>>>>> UNSUPPORTED: Profile-x86_64 :: Linux/coverage_shared.test (5 of 32)<br>
>>>>>>>>> UNSUPPORTED: Profile-x86_64 :: Linux/instrprof-comdat.test (6 of 32)<br>
>>>>>>>>> UNSUPPORTED: Profile-x86_64 :: Linux/instrprof-dlopen.test (7 of 32)<br>
>>>>>>>>> UNSUPPORTED: Profile-x86_64 ::<br>
>>>>>>>>> Linux/instrprof-dynamic-one-shared.test (8 of 32)<br>
>>>>>>>>> UNSUPPORTED: Profile-x86_64 ::<br>
>>>>>>>>> Linux/instrprof-dynamic-two-shared.test (9 of 32)<br>
>>>>>>>>><br>
>>>>>>>>> For reference, I configure llvm with: `-DCMAKE_CROSSCOMPILING=False<br>
>>>>>>>>> -DLLVM_TARGET_ARCH="X86" -DLLVM_TARGETS_TO_BUILD="X86;AArch64;ARM"<br>
>>>>>>>>> -DCMAKE_BUILD_TYPE:STRING=Debug -DLLVM_ENABLE_ASSERTIONS=True<br>
>>>>>>>>> -DLLVM_INCLUDE_TESTS=True -DLLVM_ENABLE_WARNINGS=False -G 'Ninja' ../`.<br>
>>>>>>>>><br>
>>>>>>>>> AFAICT (checking -###), the compiler is grabbing the correct copy of<br>
>>>>>>>>> compiler-rt and it has the right slice:<br>
>>>>>>>>><br>
>>>>>>>>> $ ninja check-profile [...]<br>
>>>>>>>>> $ file<br>
>>>>>>>>> "/Users/vk/Desktop/llvm/build/bin/../lib/clang/3.9.0/lib/darwin/libclang_rt.profile_osx.a"<br>
>>>>>>>>><br>
>>>>>>>>> /Users/vk/Desktop/llvm/build/bin/../lib/clang/3.9.0/lib/darwin/libclang_rt.profile_osx.a:<br>
>>>>>>>>> Mach-O universal binary with 3 architectures: [i386: current ar archive<br>
>>>>>>>>> random library] [x86_64: current ar archive random library] [x86_64h:<br>
>>>>>>>>> current ar archive random library]<br>
>>>>>>>>><br>
>>>>>>>>> /Users/vk/Desktop/llvm/build/bin/../lib/clang/3.9.0/lib/darwin/libclang_rt.profile_osx.a<br>
>>>>>>>>> (for architecture i386): current ar archive random library<br>
>>>>>>>>><br>
>>>>>>>>> /Users/vk/Desktop/llvm/build/bin/../lib/clang/3.9.0/lib/darwin/libclang_rt.profile_osx.a<br>
>>>>>>>>> (for architecture x86_64): current ar archive random library<br>
>>>>>>>>><br>
>>>>>>>>> /Users/vk/Desktop/llvm/build/bin/../lib/clang/3.9.0/lib/darwin/libclang_rt.profile_osx.a<br>
>>>>>>>>> (for architecture x86_64h): current ar archive random library<br>
>>>>>>>>><br>
>>>>>>>>> I'll try to get to the bottom of this, but any help is appreciated.<br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> Repository:<br>
>>>>>>>>> rL LLVM<br>
>>>>>>>>><br>
>>>>>>>>> <a href="http://reviews.llvm.org/D17361" rel="noreferrer" target="_blank">http://reviews.llvm.org/D17361</a><br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> llvm-commits mailing list<br>
>>>>>> <a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
>>>>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
>>>>><br>
>>>><br>
>><br>
<br>
</div></div></blockquote></div><br></div></div>