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/
next 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).