On 11/23/20 1:25 PM, Sebastian Huber wrote:
On 20/11/2020 17:14, Sebastian Huber wrote:
On 20/11/2020 16:25, Martin Liška wrote:
Apart from these 2 hooks, I bet you will also need gcov_position and gcov_seek
functions,
can be seen in my sent patch.
For what do I need them?
I prefer the way with the 2 extra hooks.
Can you please prepare a patch where the newly added functions
__gcov_info_to_gcda and __gcov_fn_info_to_gcda
will be used in libgcov (with the hooks equal to fopen and fwrite?
I am not really sure what I should do. Do you mean that write_one_data() should
be rewritten to use __gcov_info_to_gcda() with hooks that use
gcov_write_unsigned()?
The write_one_data() also has a const struct gcov_summary *prg_p pointer. What should
an external user provide for this pointer? For example &gi_ptr->summary?
The write_one_data() has this code
if (fn_buffer && fn_buffer->fn_ix == f_ix)
{
/* Buffered data from another program. */
buffered = 1;
gfi_ptr = &fn_buffer->info;
length = GCOV_TAG_FUNCTION_LENGTH;
}
which uses a global variable
/* buffer for the fn_data from another program. */
static struct gcov_fn_buffer *fn_buffer;
For this handling we would need a new hook to do this:
if (buffered)
fn_buffer = free_fn_data (gi_ptr, fn_buffer, GCOV_COUNTERS);
I don't know for what we need seek and position hooks.
Refactoring write_one_data() to use hooks requires that
gcov_write_counter()
gcov_write_tag_length()
gcov_write_summary()
move from gcc/gcov-io.c to libgcc/libgcov-buffer.c. They can be made static. I
am not sure if the external symbols can be removed
/* In libgcov we need these functions to be extern, so prefix them with
__gcov. In libgcov they must also be hidden so that the instance in
the executable is not also used in a DSO. */
#define gcov_write_tag_length __gcov_write_tag_length
#define gcov_write_counter __gcov_write_counter
#define gcov_write_summary __gcov_write_summary
without breaking anything? What is the performance impact if only
gcov_write_unsigned() is used by libgcc/libgcov-driver.c?
All right. It seems that your original patch would be a simpler approach,
I'll comment the patch in a moment.
Thanks,
Martin
