[PATCH] Indirect call target profiling compiler-rt changes

[Justin Bogner]

"Betul Buyukkurt" <betulb at codeaurora.org> writes:
>>> Index: lib/profile/InstrProfilingBuffer.c
>>> ===================================================================
>>> --- lib/profile/InstrProfilingBuffer.c
>>> +++ lib/profile/InstrProfilingBuffer.c
>>> @@ -68,11 +68,14 @@
>>>     * Match logic in __llvm_profile_write_file().
>>>     */
>>>
>>> +  __llvm_profile_value_data *ValueDataBegin = NULL;
>>> +
>>>    /* Calculate size of sections. */
>>>    const uint64_t DataSize = DataEnd - DataBegin;
>>>    const uint64_t CountersSize = CountersEnd - CountersBegin;
>>>    const uint64_t NamesSize = NamesEnd - NamesBegin;
>>>    const uint64_t Padding = sizeof(uint64_t) - NamesSize %
>>> sizeof(uint64_t);
>>> +  const uint64_t ValueDataSize = 0;
>>
>> I guess this is supposed to do:
>>
>>   __llvm_profile_gather_value_data(&ValueDataBegin);
>
> This is correct. However, on the buffer access API's the size of the
> buffer is calculated so that the caller of the write API allocates the
> necessary buffer. A pointer to the buffer is passed back to the write
> function for the data to be dumped to this memory. In my implementation, I
> kept the buffer API's unmodified - other than changing the format to match
> that of version 2's. I'd like to know if a re-alloc on the passed in (char
> *Buffer) be in order as a change to accommodate value profiling's dynamic
> memory needs.

But isn't this completely broken if someone uses value profiling and the
buffer APIs? What happens in that case?

Can we teach __llvm_profile_get_size_for_buffer to calculate the correct
size ahead of time so that a realloc isn't necessary?