[PATCH 08/12] gcov: Add functions to dump the gcov information

[Chris Johns]

On 1/7/2022 3:59 pm, Sebastian Huber wrote:
> On 01.07.22 07:48, Chris Johns wrote:
>> On 1/7/2022 3:00 pm, Sebastian Huber wrote:
>>> On 01.07.22 02:37, Chris Johns wrote:
>>>>> +void _IO_Gcov_dump_info_base64( IO_Put_char put_char, void *arg );
>>>>> +
>>>> Why just a per char interface? Given this is in the score a buffer plus length
>>>> interface would make more sense? It would make the interface more efficient.
>>>
>>> All the test output uses a single char output function. This is also used by
>>> _IO_Base64().
>>
>> That is a shame. Are you saying it is a lot of work to change?
> 
> I don't see a need for change. These are internal functions. They are not part
> of the API.

These types of patches load functionality into the score that is required to be
maintained and yet it is limited in scope in a small and simple way.

I see some of these things as powerful and a benefit to a wider part of the
community and it is exciting to see this happening. I am raising these questions
and probing what is being offered so we can understand the limitations and
possibly what might be needed.

>>>> The per char could be a convenience function version of the buffer and length
>>>> call for those use cases than want it, ie ....
>>>>
>>>>> +static void _IO_Gcov_dump( const void *data, unsigned length, void *arg )
>>>
>>> If you really need this, you can call the libgcov functions directly.
>>
>> The title of this patch to the "score" says ...
>>
>>   "gcov: Add functions to dump the gcov information"
>>
>> If I have a large app and want to use this support am I restricted to a per
>> character interface rather than a buffer and length or I implement this again
>> directly? I am not sure I understand the purpose of this code in the score?
> 
> The purpose of the score functions are to provide an implementation for
> rtems_test_gcov_dump_info(). The RTEMS test suite simply requires a character
> output function.

Yes the testsuite is limited to a per char output path. I had missed the scoping
with `rtems_test_*`.

>> Is ESA going to use this gcov coverage for their applications?
> 
> They used gcov in the past with lots of local hacks.
> 
>>
>>> I can move the linker set definition to a separate file.
>>
>> I do not know how this relates.
> 
> If we move the RTEMS_LINKER_ROSET( gcov_info, const struct gcov_info * );
> definition to a separate file, you can use __gcov_info_to_gcda() in your
> application with a custom dump function.

If that provides a path we can work towards better support for applications then
I think that would be a good thing to do.

Chris