* Gcov info registration without constructor? @ 2020-11-09 17:45 Sebastian Huber 2020-11-10 12:05 ` Martin Liška 0 siblings, 1 reply; 5+ messages in thread From: Sebastian Huber @ 2020-11-09 17:45 UTC (permalink / raw) To: gcc 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/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Gcov info registration without constructor? 2020-11-09 17:45 Gcov info registration without constructor? Sebastian Huber @ 2020-11-10 12:05 ` Martin Liška 2020-11-10 12:35 ` Sebastian Huber 0 siblings, 1 reply; 5+ messages in thread From: Martin Liška @ 2020-11-10 12:05 UTC (permalink / raw) To: Sebastian Huber, gcc 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 > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Gcov info registration without constructor? 2020-11-10 12:05 ` Martin Liška @ 2020-11-10 12:35 ` Sebastian Huber 2020-11-10 16:23 ` Sebastian Huber 0 siblings, 1 reply; 5+ messages in thread From: Sebastian Huber @ 2020-11-10 12:35 UTC (permalink / raw) To: Martin Liška, gcc 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/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Gcov info registration without constructor? 2020-11-10 12:35 ` Sebastian Huber @ 2020-11-10 16:23 ` Sebastian Huber 2020-11-10 18:13 ` Sebastian Huber 0 siblings, 1 reply; 5+ messages in thread From: Sebastian Huber @ 2020-11-10 16:23 UTC (permalink / raw) To: Martin Liška, gcc [-- 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Gcov info registration without constructor? 2020-11-10 16:23 ` Sebastian Huber @ 2020-11-10 18:13 ` Sebastian Huber 0 siblings, 0 replies; 5+ messages in thread From: Sebastian Huber @ 2020-11-10 18:13 UTC (permalink / raw) To: Martin Liška, gcc 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/ ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-11-10 18:13 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-11-09 17:45 Gcov info registration without constructor? Sebastian Huber 2020-11-10 12:05 ` Martin Liška 2020-11-10 12:35 ` Sebastian Huber 2020-11-10 16:23 ` Sebastian Huber 2020-11-10 18:13 ` Sebastian Huber
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).