public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Sebastian Huber <sebastian.huber@embedded-brains.de>
To: gcc@gcc.gnu.org
Subject: Gcov info registration without constructor?
Date: Mon, 9 Nov 2020 18:45:39 +0100	[thread overview]
Message-ID: <4c921363-879d-5c4a-cda6-f0fcce4f7719@embedded-brains.de> (raw)

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/


             reply	other threads:[~2020-11-09 17:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-09 17:45 Sebastian Huber [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4c921363-879d-5c4a-cda6-f0fcce4f7719@embedded-brains.de \
    --to=sebastian.huber@embedded-brains.de \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).