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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
