Gcov info registration without constructor?

Gcov info registration without constructor?

[Sebastian Huber]

Hello,

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?

Kind regards,

     Sebastian

-- 
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/

Re: Gcov info registration without constructor?

[Martin Liška]

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.

> 
> 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?

Martin

> 
> Kind regards,
> 
>      Sebastian
> 

Re: Gcov info registration without constructor?

[Sebastian Huber]

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/

Re: Gcov info registration without constructor?

[Sebastian Huber]

[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]

Hello Martin,

attached is a proof of concept. I am not sure how I can make the new 
section read-only. Currently, it is writable:

         .section        .gcov_info,"aw"
         .align 2
         .type   .LPBX2, @object
         .size   .LPBX2, 4
.LPBX2:
         .long   .LPBX0

I probably need also a patch for the GCC options documentation, test 
cases, a GCC bootstrap on Linux, release notes, ...? Do I have to wait 
for the GCC 11 development start?

-- 
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/


[-- Attachment #2: 0001-Add-fprofile-info-section-support.patch --]
[-- Type: text/x-patch, Size: 2557 bytes --]

From 305eb4066742418d3b14ee6e8bec76bfb2835a99 Mon Sep 17 00:00:00 2001
From: Sebastian Huber <sebastian.huber@embedded-brains.de>
Date: Tue, 10 Nov 2020 16:21:07 +0100
Subject: [PATCH] Add -fprofile-info-section support

---
 gcc/common.opt |  8 ++++++++
 gcc/coverage.c | 19 +++++++++++++++++--
 gcc/opts.c     |  4 ++++
 3 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index 7d0e0d9c88a..1b69da681e3 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2268,6 +2268,14 @@ fprofile-generate=
 Common Joined RejectNegative
 Enable common options for generating profile info for profile feedback directed optimizations, and set -fprofile-dir=.
 
+fprofile-info-section
+Common RejectNegative
+Register a pointer to the profile information in the .gcov_info section.
+
+fprofile-info-section=
+Common Joined RejectNegative Var(profile_info_section)
+Register a pointer to the profile information in the named section.
+
 fprofile-partial-training
 Common Report Var(flag_profile_partial_training) Optimization
 Do not assume that functions never executed during the train run are cold.
diff --git a/gcc/coverage.c b/gcc/coverage.c
index 7711412c3be..ec1c5d3d125 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -1151,8 +1151,23 @@ coverage_obj_init (void)
   ASM_GENERATE_INTERNAL_LABEL (name_buf, "LPBX", 0);
   DECL_NAME (gcov_info_var) = get_identifier (name_buf);
 
-  build_init_ctor (gcov_info_type);
-  build_gcov_exit_decl ();
+  if (profile_info_section)
+    {
+       tree var = build_decl (BUILTINS_LOCATION,
+			      VAR_DECL, NULL_TREE,
+			      build_pointer_type (gcov_info_type));
+       TREE_STATIC (var) = 1;
+       ASM_GENERATE_INTERNAL_LABEL (name_buf, "LPBX", 2);
+       DECL_NAME (var) = get_identifier (name_buf);
+       set_decl_section_name (var, profile_info_section);
+       DECL_INITIAL (var) = build_fold_addr_expr (gcov_info_var);
+       varpool_node::finalize_decl (var);
+    }
+  else
+    {
+      build_init_ctor (gcov_info_type);
+      build_gcov_exit_decl ();
+    }
 
   return true;
 }
diff --git a/gcc/opts.c b/gcc/opts.c
index 96291e89a49..fd6e669471e 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -2602,6 +2602,10 @@ common_handle_option (struct gcc_options *opts,
       SET_OPTION_IF_UNSET (opts, opts_set, flag_ipa_bit_cp, value);
       break;
 
+    case OPT_fprofile_info_section:
+      opts->x_profile_info_section = ".gcov_info";
+      break;
+
     case OPT_fpatchable_function_entry_:
       {
 	char *patch_area_arg = xstrdup (arg);
-- 
2.26.2

Re: Gcov info registration without constructor?

[Sebastian Huber]

On 10/11/2020 17:23, Sebastian Huber wrote:

> I am not sure how I can make the new section read-only. Currently, it 
> is writable:
>
>         .section        .gcov_info,"aw"
>         .align 2
>         .type   .LPBX2, @object
>         .size   .LPBX2, 4
> .LPBX2:
>         .long   .LPBX0 

I changed the section by adding:

        TREE_READONLY (var) = 1;
        get_section (profile_info_section, SECTION_UNNAMED, NULL);

This is the generated data:

         .section        .gcov_info,"a"
         .align 2
         .type   .LPBX2, @object
         .size   .LPBX2, 4
.LPBX2:
         .long   .LPBX0
         .section        .rodata
         .align 2

-- 
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/