From: "Martin Liška" <mliska@suse.cz>
To: David Taylor <dtaylor@emc.com>
Cc: gcc@gcc.gnu.org
Subject: Re: GCC's instrumentation and the target environment
Date: Thu, 21 Nov 2019 12:43:00 -0000 [thread overview]
Message-ID: <cb827288-056c-e64f-31d6-4dac80d38344@suse.cz> (raw)
In-Reply-To: <20745.1574262844@usendtaylorx2l>
On 11/20/19 4:14 PM, David Taylor wrote:
> Sorry for not responding sooner.
>
> Thanks Martin.
>
> Like Joel we have a third party solution to instrumentation. Part of
> my objection to the third party solution is freedom. There are
> customizations we would like, but not having source we're at the mercy
> of the vendor both for whether it gets done and the timing. Part of
> the objection is the massive amount of changes I had to make to our
> build system to integrate it and the resulting feeling of fragility.
> They are reportedly addressing the latter in a future release.
>
> By contrast, looking at GCC based instrumentation, the changes
> required to our build system are very small and easy.
Hello.
That sounds promising to me!
>
> Part of my purpose in posting was the belief that this problem --
> wanting to instrument embedded code -- is not uncommon and has likely
> been solved already. And the hope that one of the solvers would feel
> that their existing solution was in a good enough shape to contribute
> back. Or that someone would point out that there is already an
> existing {Free | Open} source solution that I am overlooking.
Well, one quite similar usage will be usage of gcov in linux kernel,
please take a look at kernel/gcov subfolder.
>
> Since no one has mentioned an existing solution, here is a first draft
> of a proposed solution to GCC instrumentation not playing well with
> embedded...
>
> NOTE: *NONE* of the following has been implemented as yet. I would
> ulimately like this to be something that once implemented would be
> considered for becoming part of standard GCC. So, if you see something
> that would impede that goal or if changed would improve its chances,
> please speak up.
>
> Add a new configure options --{with|without}-libgcov-standalone-env
>
> Default: without (i.e., hosted)
>
> Question: should hosted libgcov be the default for all configuration
> tuples? Or should it only be the default when there are headers?
> Or...?
That's a detail, so let's say we'll have an option that will come up
with a wrappers (__gcov_ # fn).
>
> When standalone, when building libgcov.a files, suppress
> -Dinhibit_libc and add -DLIBGCOV_STANDALONE_ENV to the command line
> switches.
>
> Then in libgcov-driver.c, libgcov-driver-system.c, gcov-io.c, replace
>
> all calls of fopen with calls of __gcov_open_int
> fread __gcov_read_int
> fwrite __gcov_write_int
> fclose __gcov_close_int
> fseek __gcov_seek_int
> ftell __gcov_tell_int
>
> setbuf __gcov_setbuf_int
>
> Probably belongs inside __gcov_open_int instead of as
> a separate routine.
>
> getenv __gcov_getenv_int
>
> abort __gcov_abort_int
>
> When the application is 'the kernel' or 'the system',
> abort isn't really an option.
>
> fprintf __gcov_fprintf_int
>
> This is called in two places -- gcov_error and
> gcov_exit_open_gcda_file. The latter hard codes the
> stream as stderr; the former calls get_gcov_error_file
> to get the stream (which defaults to stderr but can be
> overridded via an environment variable).
>
> I think that get_gcov_error_file should be renamed to
> __gcov_get_error_file, be made non-static, and be
> called by gcov_exit_open_gcda_file instead of hard
> coding stderr.
>
> For that matter, I feel that gcov_exit_open_gcda_file
> should just call __gcov_error instead of doing it's
> own error reporting. And __gcov_get_error_file and
> __gcov_error should be a replacable routines as
> embedded systems might well have a different way of
> reporting errors.
>
> vfprintf __gcov_vfprintf_int
>
> If gcov_open_gcda_file is altered to call
> __gcov_error and __gcov_error becomes a replacable
> routine, then fprintf and vfprintf do not need to be
> wrapped.
>
> malloc __gcov_malloc_int
> free __gcov_free_int
>
> Embedded applications often do memory allocation
> differently.
>
> While I think that the above list is complete, I wouldn't be surprised
> if I missed one or two.
That seams reasonable to me and can be easily achieved by a macro that
will either expand to __gcov # fn _ int, or to fn. I can imagine that.
>
> Other than __gcov_open_int, there would be no conflict if the _int was
> left off the end. I put it on to emphasize that these routines were
> not meant to be called by the user, but rather are provided by the
> user. Some other naming convention might be better.
>
> There would be a new header file, included as appropriate. If the
> normal (hosted) build was in effect, then some new (potentially one
> line static inline) functions would be defined for each of the above
> functions that just call the expected standard libc function. If the
> embedded (standalone) build was in effect, then there would be extern
> declarations for each of the above, but *NO* definition -- the
> definition would be the reposibility of the application.
As mentioned, a macro expansion can do that. And the last missing step,
which you will use, will be linking with additional library that will
implement all the __gcov_fn_int functions.
The suggested approach will need only quite minimal changes to the current
libgcov.
Martin
>
> Comments?
>
> David
>
next prev parent reply other threads:[~2019-11-21 12:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-20 15:22 David Taylor
2019-11-21 12:43 ` Martin Liška [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-11-01 18:18 David Taylor
2019-11-04 9:19 ` Martin Liška
2019-11-04 13:06 ` David.Taylor
2019-11-04 13:45 ` Joel Sherrill
2019-11-06 8:04 ` Martin Liška
2020-11-14 13:04 ` 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=cb827288-056c-e64f-31d6-4dac80d38344@suse.cz \
--to=mliska@suse.cz \
--cc=dtaylor@emc.com \
--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).