Re: Gcov info registration without constructor?

[Sebastian Huber <sebastian.huber@embedded-brains.de>]

Hallo Martin,

On 10/11/2020 13:05, Martin Liška wrote:
> On 11/9/20 6:45 PM, Sebastian Huber wrote:
>> Hello,
>
> Hello.
>
> There was a similar need some time ago:
> https://gcc.gnu.org/legacy-ml/gcc/2019-11/msg00009.html
>
> Please take a look for a possible inspiration.
thanks for the pointer.
>
>>
>> I would like to use the -ftest-coverage -fprofile-arcs support on a 
>> bare metal system (no operating system or very early stages in the 
>> system startup). In this environment I cannot use the gcov info 
>> registration via a constructor and __gcov_init(), because there may 
>> be some other (more complex) constructors registered which cannot be 
>> called at this stage.. Would it be acceptable to add a compiler 
>> option which changes the gcov info registration via a constructor to 
>> a linker set? If enabled, then for each translation unit (see 
>> coverage_obj_init()) a pointer to the gcov info is placed into a 
>> special linker section (for example .gcov_info). The linker script 
>> collects all .gcov_info data and adds a begin/end symbol. The runtime 
>> support can then iterate over all linker section entries (pointers to 
>> struct gcov_info) to dump the aggregated gcov data during program 
>> termination. Would such changes be acceptable for GCC integration or 
>> is this too specific?
>
> That's definitely something we can support. Similarly to the linked 
> message, are you capable of using
> normal system I/O to stream .gcda files? 

I cannot use I/O to files. I also cannot use dynamic memory (e.g. 
malloc()). This is actually not an issue, since it is very easy to dump 
the gcov info via a simple character output function as plain text. In 
the Linux kernel see for example convert_to_gcda() in 
"kernel/gcov/gcc_4_7.c". Instead of copying the data to a buffer you can 
directly output the data via some printk() function. On the host 
computer you can collect the text and generate the .gcda files.

I guess the first thing we need is a name for the option. What about:

-fprofile-info-section

-fprofile-info-section=name

Register a pointer to the profile information generated by 
-fprofile-arcs in the named section for each translation unit. If name 
is not given, then .gcov_info will be used. This option disables the 
profile information registration through a constructor and it disables 
the profile information processing through a destructor. This option can 
be used to support profiling in environments which do not support 
constructors and destructors. The linker could collect the content of 
the named section in a continuous memory block and add begin and end 
symbols. The runtime support could dump the profiling information 
registered in this linker set during program termination to a serial 
line for example.

-- 
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
Phone: +49-89-18 94 741 - 16
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

embedded brains GmbH
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/