GCC's instrumentation and the target environment

[Martin Liška]

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
>