Re: [PATCH] gcov: Add __gcov_info_to_gdca()
On 13/07/2021 15:03, Sebastian Huber wrote: memset (list_sizes, 0, counters * sizeof (unsigned)); Sorry, I just realized that memset() cannot be used if inhibit_libc is defined. I will send a v2 of the patch. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 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/
[PATCH] gcov: Add __gcov_info_to_gdca()
Add __gcov_info_to_gcda() to libgcov to get the gcda data for a gcda info in a
free-standing environment. It is intended to be used with the
-fprofile-info-section option. A crude test program which doesn't use a linker
script is (use "gcc -coverage -fprofile-info-section -lgcc test.c" to compile
it):
#include
#include
#include
extern const struct gcov_info *my_info;
static void
filename (const char *f, void *arg)
{
printf("filename: %s\n", f);
}
static void
dump (const void *d, unsigned n, void *arg)
{
const unsigned char *c = d;
for (unsigned i = 0; i < n; ++i)
printf ("%02x", c[i]);
}
static void *
allocate (unsigned length, void *arg)
{
return malloc (length);
}
int main()
{
__asm__ volatile (".set my_info, .LPBX2");
__gcov_info_to_gcda (my_info, filename, dump, allocate, NULL);
return 0;
}
gcc/
* gcc/gcov-io.h (gcov_write): Declare.
* gcc/gcov-io.c (gcov_write): New.
* doc/invoke.texi (fprofile-info-section): Mention
__gcov_info_to_gdca().
libgcc/
Makefile.in (LIBGCOV_DRIVER): Add _gcov_info_to_gcda.
gcov.h (gcov_info): Declare.
(__gcov_info_to_gdca): Likewise.
libgcov-driver.c (are_all_counters_zero): New.
(dump_handler): Likewise.
(allocate_handler): Likewise.
(dump_unsigned): Likewise.
(dump_counter): Likewise.
(write_topn_counters): Add dump, allocate, and arg parameters. Use
dump_unsigned() and dump_counter().
(write_one_data): Add dump, allocate, and arg parameters. Use
dump_unsigned(), dump_counter(), and are_all_counters_zero().
(__gcov_info_to_gcda): New.
---
gcc/doc/invoke.texi | 80 ++---
gcc/gcov-io.c | 10 +++
gcc/gcov-io.h | 1 +
libgcc/Makefile.in | 2 +-
libgcc/gcov.h | 17 +
libgcc/libgcov-driver.c | 155 +++-
6 files changed, 218 insertions(+), 47 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index e67d47af676d..2c514acf2003 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -14782,17 +14782,17 @@ To optimize the program based on the collected
profile information, use
Register the profile information in the specified section instead of using a
constructor/destructor. The section name is @var{name} if it is specified,
otherwise the section name defaults to @code{.gcov_info}. A pointer to the
-profile information generated by @option{-fprofile-arcs} or
-@option{-ftest-coverage} is placed in the specified section for each
-translation unit. This option disables the profile information registration
-through a constructor and it disables the profile information processing
-through a destructor. This option is not intended to be used in hosted
-environments such as GNU/Linux. It targets systems with limited resources
-which do not support constructors and destructors. The linker could collect
-the input sections in a continuous memory block and define start 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. A
-GNU linker script example which defines a linker output section follows:
+profile information generated by @option{-fprofile-arcs} is placed in the
+specified section for each translation unit. This option disables the profile
+information registration through a constructor and it disables the profile
+information processing through a destructor. This option is not intended to be
+used in hosted environments such as GNU/Linux. It targets free-standing
+environments (for example embedded systems) with limited resources which do not
+support constructors/destructors or the C library file I/O.
+
+The linker could collect the input sections in a continuous memory block and
+define start and end symbols. A GNU linker script example which defines a
+linker output section follows:
@smallexample
.gcov_info :
@@ -14803,6 +14803,64 @@ GNU linker script example which defines a linker
output section follows:
@}
@end smallexample
+The program could dump the profiling information registered in this linker set
+for example like this:
+
+@smallexample
+#include
+#include
+#include
+
+extern const struct gcov_info *__gcov_info_start[];
+extern const struct gcov_info *__gcov_info_end[];
+
+static void
+filename (const char *f, void *arg)
+@{
+ puts (f);
+@}
+
+static void
+dump (const void *d, unsigned n, void *arg)
+@{
+ const unsigned char *c = d;
+
+ for (unsigned i = 0; i < n; ++i)
+printf ("%02x", c[i]);
+@}
+
+static void *
+allocate (unsigned length, void *arg)
+@{
+ return malloc (length);
+@}
+
+static void
+dump_gcov_info (void)
+@{
+ const struct gcov_info **info = __gcov_info_start;
+ const struct gcov_info **end = __gcov_info_end;
+
+ /* Obfuscate variable to prevent
Re: [PATCH] gcov: Add __gcov_info_to_gdca()
On 11/23/20 3:50 PM, Sebastian Huber wrote: On 23/11/2020 15:49, Martin Liška wrote: On 11/23/20 3:35 PM, Sebastian Huber wrote: If I have to wait for next stage 1, I can also try to refactor write_one_data() after your patch which removes the buffering. Yes, please build your patches on top of the file buffering removal. Ok. This would avoid some duplicated code, however, it would require some changes in existing code. Is it allowed to remove external (hidden?) symbols from libgcov? Which functions do you mean? Refactoring write_one_data() to use hooks requires that gcov_write_counter() gcov_write_tag_length() gcov_write_summary() I bet these 3 can be actually moved to gcov-io.h, these functions are very small. So yes, it should be doable. Martin move from gcc/gcov-io.c to libgcc/libgcov-buffer.c. They can be made static. I am not sure if the external symbols can be removed /* In libgcov we need these functions to be extern, so prefix them with __gcov. In libgcov they must also be hidden so that the instance in the executable is not also used in a DSO. */ #define gcov_write_tag_length __gcov_write_tag_length #define gcov_write_counter __gcov_write_counter #define gcov_write_summary __gcov_write_summary
Re: [PATCH] gcov: Add __gcov_info_to_gdca()
On 23/11/2020 15:49, Martin Liška wrote: On 11/23/20 3:35 PM, Sebastian Huber wrote: If I have to wait for next stage 1, I can also try to refactor write_one_data() after your patch which removes the buffering. Yes, please build your patches on top of the file buffering removal. Ok. This would avoid some duplicated code, however, it would require some changes in existing code. Is it allowed to remove external (hidden?) symbols from libgcov? Which functions do you mean? Refactoring write_one_data() to use hooks requires that gcov_write_counter() gcov_write_tag_length() gcov_write_summary() move from gcc/gcov-io.c to libgcc/libgcov-buffer.c. They can be made static. I am not sure if the external symbols can be removed /* In libgcov we need these functions to be extern, so prefix them with __gcov. In libgcov they must also be hidden so that the instance in the executable is not also used in a DSO. */ #define gcov_write_tag_length __gcov_write_tag_length #define gcov_write_counter __gcov_write_counter #define gcov_write_summary __gcov_write_summary -- embedded brains GmbH Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@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/
Re: [PATCH] gcov: Add __gcov_info_to_gdca()
On 11/23/20 3:35 PM, Sebastian Huber wrote: If I have to wait for next stage 1, I can also try to refactor write_one_data() after your patch which removes the buffering. Yes, please build your patches on top of the file buffering removal. This would avoid some duplicated code, however, it would require some changes in existing code. Is it allowed to remove external (hidden?) symbols from libgcov? Which functions do you mean? Martin
Re: [PATCH] gcov: Add __gcov_info_to_gdca()
Hello Martin,
On 23/11/2020 15:30, Martin Liška wrote:
+/* Convert the gcov info to a gcda data stream. This function does
not support
+ whole program statistics and top counters. It is intended for
free-standing
+ environments which do not support the C library file I/O. For the
data
+ format, see also write_one_data(). */
+
+void
+__gcov_info_to_gcda (const struct gcov_info *gi_ptr,
+ void (*filename) (const char *, void *),
+ void (*dump) (const void *, unsigned, void *),
+ void *arg)
Hello.
I would prefer a better names for the hooks. What about something like
open_filename_hook and write_data_hook?
+{
+ (*filename) (gi_ptr->filename, arg);
+ gcov_unsigned_t word = GCOV_DATA_MAGIC;
+ (*dump) (, sizeof (word), arg);
And I would add a new macro like
#define GCOV_WRITE_DATA(data) (*write_data_hook) (, sizeof
(DATA), arg
What do you think?
sounds good.
Note that we already entered a code freeze before the patch was sent
to the mailing list.
That means we can install it in the next stage1.
If I have to wait for next stage 1, I can also try to refactor
write_one_data() after your patch which removes the buffering. This
would avoid some duplicated code, however, it would require some changes
in existing code. Is it allowed to remove external (hidden?) symbols
from libgcov?
--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@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/
Re: [PATCH] gcov: Add __gcov_info_to_gdca()
On 11/17/20 10:57 AM, Sebastian Huber wrote:
This is a proposal to get the gcda data for a gcda info in a free-standing
environment. It is intended to be used with the -fprofile-info-section option.
A crude test program which doesn't use a linker script is:
#include
#include
extern const struct gcov_info *my_info;
static void
filename(const char *f, void *arg)
{
printf("filename: %s\n", f);
}
static void
dump(const void *d, unsigned n, void *arg)
{
const unsigned char *c;
unsigned i;
c = d;
for (i = 0; i < n; ++i) {
printf("%02x", c[i]);
}
}
int main()
{
__asm__ volatile (".set my_info, .LPBX2");
__gcov_info_to_gcda(my_info, filename, dump, NULL);
return 0;
}
gcc/
* doc/invoke.texi (fprofile-info-section): Mention
__gcov_info_to_gdca().
libgcc/
Makefile.in (LIBGCOV_DRIVER): Add _gcov_info_to_gcda.
gcov.h (gcov_info): Declare.
(__gcov_info_to_gdca): Likewise.
libgcov-driver.c (gcov_are_all_counters_zero): New.
(write_one_data): Use gcov_are_all_counters_zero().
(gcov_fn_info_to_gcda): New.
(__gcov_info_to_gcda): Likewise.
---
gcc/doc/invoke.texi | 73
libgcc/Makefile.in | 2 +-
libgcc/gcov.h | 15 +
libgcc/libgcov-driver.c | 120
4 files changed, 188 insertions(+), 22 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 3510a54c6c4..09cb4922f5e 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -14248,17 +14248,17 @@ To optimize the program based on the collected
profile information, use
Register the profile information in the specified section instead of using a
constructor/destructor. The section name is @var{name} if it is specified,
otherwise the section name defaults to @code{.gcov_info}. A pointer to the
-profile information generated by @option{-fprofile-arcs} or
-@option{-ftest-coverage} is placed in the specified section for each
-translation unit. This option disables the profile information registration
-through a constructor and it disables the profile information processing
-through a destructor. This option is not intended to be used in hosted
-environments such as GNU/Linux. It targets systems with limited resources
-which do not support constructors and destructors. The linker could collect
-the input sections in a continuous memory block and define start 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. A
-GNU linker script example which defines a linker output section follows:
+profile information generated by @option{-fprofile-arcs} is placed in the
+specified section for each translation unit. This option disables the profile
+information registration through a constructor and it disables the profile
+information processing through a destructor. This option is not intended to be
+used in hosted environments such as GNU/Linux. It targets free-standing
+environments (for example embedded systems) with limited resources which do not
+support constructors/destructors or the C library file I/O.
+
+The linker could collect the input sections in a continuous memory block and
+define start and end symbols. A GNU linker script example which defines a
+linker output section follows:
@smallexample
.gcov_info :
@@ -14269,6 +14269,57 @@ GNU linker script example which defines a linker
output section follows:
@}
@end smallexample
+The program could dump the profiling information registered in this linker set
+for example like this:
+
+@smallexample
+#include
+#include
+
+extern const struct gcov_info *__gcov_info_start[];
+extern const struct gcov_info *__gcov_info_end[];
+
+static void
+filename (const char *f, void *arg)
+@{
+ puts (f);
+@}
+
+static void
+dump (const void *d, unsigned n, void *arg)
+@{
+ const unsigned char *c = d;
+
+ for (unsigned i = 0; i < n; ++i)
+printf ("%02x", c[i]);
+@}
+
+static void
+dump_gcov_info (void)
+@{
+ const struct gcov_info **info = __gcov_info_start;
+ const struct gcov_info **end = __gcov_info_end;
+
+ /* Obfuscate variable to prevent compiler optimizations. */
+ __asm__ ("" : "+r" (end));
+
+ while (info != end)
+ @{
+void *arg = NULL;
+__gcov_info_to_gcda (*info, filename, dump, arg);
+putchar ('\n');
+++info;
+ @}
+@}
+
+int
+main()
+@{
+ dump_gcov_info();
+ return 0;
+@}
+@end smallexample
+
@item -fprofile-note=@var{path}
@opindex fprofile-note
diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
index d6075d32bd4..c22413d768c 100644
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -908,7 +908,7 @@ LIBGCOV_INTERFACE = _gcov_dump _gcov_fork
\
_gcov_execl _gcov_execlp\
Re: [PATCH] gcov: Add __gcov_info_to_gdca()
On 11/23/20 1:25 PM, Sebastian Huber wrote:
On 20/11/2020 17:14, Sebastian Huber wrote:
On 20/11/2020 16:25, Martin Liška wrote:
Apart from these 2 hooks, I bet you will also need gcov_position and gcov_seek
functions,
can be seen in my sent patch.
For what do I need them?
I prefer the way with the 2 extra hooks.
Can you please prepare a patch where the newly added functions
__gcov_info_to_gcda and __gcov_fn_info_to_gcda
will be used in libgcov (with the hooks equal to fopen and fwrite?
I am not really sure what I should do. Do you mean that write_one_data() should
be rewritten to use __gcov_info_to_gcda() with hooks that use
gcov_write_unsigned()?
The write_one_data() also has a const struct gcov_summary *prg_p pointer. What should
an external user provide for this pointer? For example _ptr->summary?
The write_one_data() has this code
if (fn_buffer && fn_buffer->fn_ix == f_ix)
{
/* Buffered data from another program. */
buffered = 1;
gfi_ptr = _buffer->info;
length = GCOV_TAG_FUNCTION_LENGTH;
}
which uses a global variable
/* buffer for the fn_data from another program. */
static struct gcov_fn_buffer *fn_buffer;
For this handling we would need a new hook to do this:
if (buffered)
fn_buffer = free_fn_data (gi_ptr, fn_buffer, GCOV_COUNTERS);
I don't know for what we need seek and position hooks.
Refactoring write_one_data() to use hooks requires that
gcov_write_counter()
gcov_write_tag_length()
gcov_write_summary()
move from gcc/gcov-io.c to libgcc/libgcov-buffer.c. They can be made static. I
am not sure if the external symbols can be removed
/* In libgcov we need these functions to be extern, so prefix them with
__gcov. In libgcov they must also be hidden so that the instance in
the executable is not also used in a DSO. */
#define gcov_write_tag_length __gcov_write_tag_length
#define gcov_write_counter __gcov_write_counter
#define gcov_write_summary __gcov_write_summary
without breaking anything? What is the performance impact if only
gcov_write_unsigned() is used by libgcc/libgcov-driver.c?
All right. It seems that your original patch would be a simpler approach,
I'll comment the patch in a moment.
Thanks,
Martin
Re: [PATCH] gcov: Add __gcov_info_to_gdca()
On 20/11/2020 17:14, Sebastian Huber wrote:
On 20/11/2020 16:25, Martin Liška wrote:
Apart from these 2 hooks, I bet you will also need gcov_position
and gcov_seek functions,
can be seen in my sent patch.
For what do I need them?
I prefer the way with the 2 extra hooks.
Can you please prepare a patch where the newly added functions
__gcov_info_to_gcda and __gcov_fn_info_to_gcda
will be used in libgcov (with the hooks equal to fopen and fwrite?
I am not really sure what I should do. Do you mean that
write_one_data() should be rewritten to use __gcov_info_to_gcda() with
hooks that use gcov_write_unsigned()?
The write_one_data() also has a const struct gcov_summary *prg_p
pointer. What should an external user provide for this pointer? For
example _ptr->summary?
The write_one_data() has this code
if (fn_buffer && fn_buffer->fn_ix == f_ix)
{
/* Buffered data from another program. */
buffered = 1;
gfi_ptr = _buffer->info;
length = GCOV_TAG_FUNCTION_LENGTH;
}
which uses a global variable
/* buffer for the fn_data from another program. */
static struct gcov_fn_buffer *fn_buffer;
For this handling we would need a new hook to do this:
if (buffered)
fn_buffer = free_fn_data (gi_ptr, fn_buffer, GCOV_COUNTERS);
I don't know for what we need seek and position hooks.
Refactoring write_one_data() to use hooks requires that
gcov_write_counter()
gcov_write_tag_length()
gcov_write_summary()
move from gcc/gcov-io.c to libgcc/libgcov-buffer.c. They can be made
static. I am not sure if the external symbols can be removed
/* In libgcov we need these functions to be extern, so prefix them with
__gcov. In libgcov they must also be hidden so that the instance in
the executable is not also used in a DSO. */
#define gcov_write_tag_length __gcov_write_tag_length
#define gcov_write_counter __gcov_write_counter
#define gcov_write_summary __gcov_write_summary
without breaking anything? What is the performance impact if only
gcov_write_unsigned() is used by libgcc/libgcov-driver.c?
--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@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/
Re: [PATCH] gcov: Add __gcov_info_to_gdca()
On 20/11/2020 16:25, Martin Liška wrote:
Apart from these 2 hooks, I bet you will also need gcov_position and
gcov_seek functions,
can be seen in my sent patch.
For what do I need them?
I prefer the way with the 2 extra hooks.
Can you please prepare a patch where the newly added functions
__gcov_info_to_gcda and __gcov_fn_info_to_gcda
will be used in libgcov (with the hooks equal to fopen and fwrite?
I am not really sure what I should do. Do you mean that write_one_data()
should be rewritten to use __gcov_info_to_gcda() with hooks that use
gcov_write_unsigned()?
The write_one_data() also has a const struct gcov_summary *prg_p
pointer. What should an external user provide for this pointer? For
example _ptr->summary?
The write_one_data() has this code
if (fn_buffer && fn_buffer->fn_ix == f_ix)
{
/* Buffered data from another program. */
buffered = 1;
gfi_ptr = _buffer->info;
length = GCOV_TAG_FUNCTION_LENGTH;
}
which uses a global variable
/* buffer for the fn_data from another program. */
static struct gcov_fn_buffer *fn_buffer;
For this handling we would need a new hook to do this:
if (buffered)
fn_buffer = free_fn_data (gi_ptr, fn_buffer, GCOV_COUNTERS);
I don't know for what we need seek and position hooks.
--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@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/
Re: [PATCH] gcov: Add __gcov_info_to_gdca()
On 11/20/20 11:11 AM, Sebastian Huber wrote:
On 20/11/2020 10:49, Martin Liška wrote:
On 11/20/20 10:25 AM, Sebastian Huber wrote:
On 20/11/2020 09:37, Martin Liška wrote:
On 11/17/20 10:57 AM, Sebastian Huber wrote:
This is a proposal to get the gcda data for a gcda info in a free-standing
environment. It is intended to be used with the -fprofile-info-section option.
A crude test program which doesn't use a linker script is:
Hello.
I'm not pretty sure how this set up is going to work. Can you please explain me
that?
I was thinking about your needs and I can imagine various techniques how to
generate
gcda files format:
1) embedded system can override fopen, fwrite, fseek to a functions that do a
remote
write-related functions
Yes, this is one option, however, the inhibit_libc disables quite a lot of
libgcov functionality if Newlib is used for example.
I see. Btw do you have available Newlib in the embedded environment? If so,
what I/O functionality is provided?
Yes, I use Newlib with the RTEMS real-time operating system. Newlib provides
the standard C library I/O functions (fopen, etc.). However, having Newlib
available doesn't mean that every application uses its. Applications are
statically linked with the operating system and Newlib. They only use what is
required. Some applications cannot use the standard C library I/O since they
use a lot of infrastructure and memory. You can do a lot of things with just a
couple of KiBs available.
I see.
2) - use -fprofile-info-section
- run an app on an embedded system and do a memory dump to a terminal/console
- take the memory dump to a host system (with IO), run
__gcov_init_from_memory_dump (...)
and then do a normal __gcov_dump
I am not sure if a plain memory dump really simplifies things. You have to get
the filename separately since it is only referenced in gcov_info and not
included in the structure:
struct gcov_info
{
[...]
const char *filename; /* output file name */
[...]
#ifndef IN_GCOV_TOOL
const struct gcov_fn_info *const *functions; /* pointer to pointers
to function information */
[...]
#endif /* !IN_GCOV_TOOL */
};
I see!
Also the gcov_fn_info is not embedded in the gcov_info structure. If you do a
plain memory dump, then you dump also pointers and how do you deal with these
pointers on the host? You would need some extra information to describe the
memory dump. So, why not use the gcda format for this? It is also more compact
since zero value counters are skipped. Serial lines are slow, so less data to
transfer is good.
/* Convert the gcov information to a gcda data stream. The first callback is
called exactly once with the filename associated with the gcov information.
The filename may be NULL. Afterwards, the second callback is subsequently
called with chunks (the begin and length of the chunk are passed as the
first two arguments) of the gcda data stream. The fourth parameter is a
user-provided argument passed as the last argument to the callback
functions. */
extern void __gcov_info_to_gcda (const struct gcov_info *gi_ptr,
void (*filename) (const char *name, void *arg),
void (*dump) (const void *begin, unsigned size, void *arg),
void *arg);
If __gcov_info_to_gcda() is correctly implemented, then this should give you
directly gcda files if you use something like this:
#include
#include
extern const struct gcov_info *__gcov_info_start[];
extern const struct gcov_info *__gcov_info_end[];
static void
filename (const char *f, void *arg)
{
FILE **file = arg;
*file = fopen(f, "rb");
}
static void
dump (const void *d, unsigned n, void *arg)
{
FILE **file = arg;
fwrite(d, n, 1, *file);
}
static void
dump_gcov_info (void)
{
const struct gcov_info **info = __gcov_info_start;
const struct gcov_info **end = __gcov_info_end;
/* Obfuscate variable to prevent compiler optimizations. */
__asm__ ("" : "+r" (end));
while (info != end)
{
FILE *file = NULL;
__gcov_info_to_gcda (*info, filename, dump, );
fclose(file);
++info;
}
}
int
main()
{
dump_gcov_info();
return 0;
}
The callback functions give the user the full control how the data of the gcda
file is encoded for the transfer to a host. No gcov internals are exposed.
All right. Btw. how will you implement these 2 callbacks on the embedded target?
One options is to convert the gcov info to YAML:
gcov-info:
- file: filename1
data: <... base64 encoded data from __gcov_info_to_gcda ... >
- file: filename2
data: ...
Then send the data to the host via a serial line. On the host read the data,
parse the YAML, and create the gcda files. The __gcov_info_to_gcda() needs
about 408 bytes of ARM Thumb-2 code and no data. You need a polled character
output function, the linker set iteration and two callbacks. So, you can
Re: [PATCH] gcov: Add __gcov_info_to_gdca()
On 20/11/2020 10:49, Martin Liška wrote:
On 11/20/20 10:25 AM, Sebastian Huber wrote:
On 20/11/2020 09:37, Martin Liška wrote:
On 11/17/20 10:57 AM, Sebastian Huber wrote:
This is a proposal to get the gcda data for a gcda info in a
free-standing
environment. It is intended to be used with the
-fprofile-info-section option.
A crude test program which doesn't use a linker script is:
Hello.
I'm not pretty sure how this set up is going to work. Can you please
explain me that?
I was thinking about your needs and I can imagine various techniques
how to generate
gcda files format:
1) embedded system can override fopen, fwrite, fseek to a functions
that do a remote
write-related functions
Yes, this is one option, however, the inhibit_libc disables quite a
lot of libgcov functionality if Newlib is used for example.
I see. Btw do you have available Newlib in the embedded environment?
If so, what I/O functionality is provided?
Yes, I use Newlib with the RTEMS real-time operating system. Newlib
provides the standard C library I/O functions (fopen, etc.). However,
having Newlib available doesn't mean that every application uses its.
Applications are statically linked with the operating system and Newlib.
They only use what is required. Some applications cannot use the
standard C library I/O since they use a lot of infrastructure and
memory. You can do a lot of things with just a couple of KiBs available.
2) - use -fprofile-info-section
- run an app on an embedded system and do a memory dump to a
terminal/console
- take the memory dump to a host system (with IO), run
__gcov_init_from_memory_dump (...)
and then do a normal __gcov_dump
I am not sure if a plain memory dump really simplifies things. You
have to get the filename separately since it is only referenced in
gcov_info and not included in the structure:
struct gcov_info
{
[...]
const char *filename; /* output file name */
[...]
#ifndef IN_GCOV_TOOL
const struct gcov_fn_info *const *functions; /* pointer to pointers
to function
information */
[...]
#endif /* !IN_GCOV_TOOL */
};
I see!
Also the gcov_fn_info is not embedded in the gcov_info structure. If
you do a plain memory dump, then you dump also pointers and how do
you deal with these pointers on the host? You would need some extra
information to describe the memory dump. So, why not use the gcda
format for this? It is also more compact since zero value counters
are skipped. Serial lines are slow, so less data to transfer is good.
/* Convert the gcov information to a gcda data stream. The first
callback is
called exactly once with the filename associated with the gcov
information.
The filename may be NULL. Afterwards, the second callback is
subsequently
called with chunks (the begin and length of the chunk are passed
as the
first two arguments) of the gcda data stream. The fourth
parameter is a
user-provided argument passed as the last argument to the callback
functions. */
extern void __gcov_info_to_gcda (const struct gcov_info *gi_ptr,
void (*filename) (const char *name, void *arg),
void (*dump) (const void *begin, unsigned size,
void *arg),
void *arg);
If __gcov_info_to_gcda() is correctly implemented, then this should
give you directly gcda files if you use something like this:
#include
#include
extern const struct gcov_info *__gcov_info_start[];
extern const struct gcov_info *__gcov_info_end[];
static void
filename (const char *f, void *arg)
{
FILE **file = arg;
*file = fopen(f, "rb");
}
static void
dump (const void *d, unsigned n, void *arg)
{
FILE **file = arg;
fwrite(d, n, 1, *file);
}
static void
dump_gcov_info (void)
{
const struct gcov_info **info = __gcov_info_start;
const struct gcov_info **end = __gcov_info_end;
/* Obfuscate variable to prevent compiler optimizations. */
__asm__ ("" : "+r" (end));
while (info != end)
{
FILE *file = NULL;
__gcov_info_to_gcda (*info, filename, dump, );
fclose(file);
++info;
}
}
int
main()
{
dump_gcov_info();
return 0;
}
The callback functions give the user the full control how the data of
the gcda file is encoded for the transfer to a host. No gcov
internals are exposed.
All right. Btw. how will you implement these 2 callbacks on the
embedded target?
One options is to convert the gcov info to YAML:
gcov-info:
- file: filename1
data: <... base64 encoded data from __gcov_info_to_gcda ... >
- file: filename2
data: ...
Then send the data to the host via a serial line. On the host read the
data, parse the YAML, and create the gcda files. The
__gcov_info_to_gcda() needs about 408 bytes of ARM Thumb-2 code and no
data. You need a polled character output function, the linker set
iteration and two callbacks. So, you can easily dump the gcov
information
Re: [PATCH] gcov: Add __gcov_info_to_gdca()
On 11/20/20 10:25 AM, Sebastian Huber wrote:
On 20/11/2020 09:37, Martin Liška wrote:
On 11/17/20 10:57 AM, Sebastian Huber wrote:
This is a proposal to get the gcda data for a gcda info in a free-standing
environment. It is intended to be used with the -fprofile-info-section option.
A crude test program which doesn't use a linker script is:
Hello.
I'm not pretty sure how this set up is going to work. Can you please explain me
that?
I was thinking about your needs and I can imagine various techniques how to
generate
gcda files format:
1) embedded system can override fopen, fwrite, fseek to a functions that do a
remote
write-related functions
Yes, this is one option, however, the inhibit_libc disables quite a lot of
libgcov functionality if Newlib is used for example.
I see. Btw do you have available Newlib in the embedded environment? If so,
what I/O functionality is provided?
2) - use -fprofile-info-section
- run an app on an embedded system and do a memory dump to a terminal/console
- take the memory dump to a host system (with IO), run
__gcov_init_from_memory_dump (...)
and then do a normal __gcov_dump
I am not sure if a plain memory dump really simplifies things. You have to get
the filename separately since it is only referenced in gcov_info and not
included in the structure:
struct gcov_info
{
[...]
const char *filename; /* output file name */
[...]
#ifndef IN_GCOV_TOOL
const struct gcov_fn_info *const *functions; /* pointer to pointers
to function information */
[...]
#endif /* !IN_GCOV_TOOL */
};
I see!
Also the gcov_fn_info is not embedded in the gcov_info structure. If you do a
plain memory dump, then you dump also pointers and how do you deal with these
pointers on the host? You would need some extra information to describe the
memory dump. So, why not use the gcda format for this? It is also more compact
since zero value counters are skipped. Serial lines are slow, so less data to
transfer is good.
/* Convert the gcov information to a gcda data stream. The first callback is
called exactly once with the filename associated with the gcov information.
The filename may be NULL. Afterwards, the second callback is subsequently
called with chunks (the begin and length of the chunk are passed as the
first two arguments) of the gcda data stream. The fourth parameter is a
user-provided argument passed as the last argument to the callback
functions. */
extern void __gcov_info_to_gcda (const struct gcov_info *gi_ptr,
void (*filename) (const char *name, void *arg),
void (*dump) (const void *begin, unsigned size, void *arg),
void *arg);
If __gcov_info_to_gcda() is correctly implemented, then this should give you
directly gcda files if you use something like this:
#include
#include
extern const struct gcov_info *__gcov_info_start[];
extern const struct gcov_info *__gcov_info_end[];
static void
filename (const char *f, void *arg)
{
FILE **file = arg;
*file = fopen(f, "rb");
}
static void
dump (const void *d, unsigned n, void *arg)
{
FILE **file = arg;
fwrite(d, n, 1, *file);
}
static void
dump_gcov_info (void)
{
const struct gcov_info **info = __gcov_info_start;
const struct gcov_info **end = __gcov_info_end;
/* Obfuscate variable to prevent compiler optimizations. */
__asm__ ("" : "+r" (end));
while (info != end)
{
FILE *file = NULL;
__gcov_info_to_gcda (*info, filename, dump, );
fclose(file);
++info;
}
}
int
main()
{
dump_gcov_info();
return 0;
}
The callback functions give the user the full control how the data of the gcda
file is encoded for the transfer to a host. No gcov internals are exposed.
All right. Btw. how will you implement these 2 callbacks on the embedded target?
Apart from these 2 hooks, I bet you will also need gcov_position and gcov_seek
functions,
can be seen in my sent patch.
Martin
Re: [PATCH] gcov: Add __gcov_info_to_gdca()
On 20/11/2020 09:37, Martin Liška wrote:
On 11/17/20 10:57 AM, Sebastian Huber wrote:
This is a proposal to get the gcda data for a gcda info in a
free-standing
environment. It is intended to be used with the
-fprofile-info-section option.
A crude test program which doesn't use a linker script is:
Hello.
I'm not pretty sure how this set up is going to work. Can you please
explain me that?
I was thinking about your needs and I can imagine various techniques
how to generate
gcda files format:
1) embedded system can override fopen, fwrite, fseek to a functions
that do a remote
write-related functions
Yes, this is one option, however, the inhibit_libc disables quite a lot
of libgcov functionality if Newlib is used for example.
2) - use -fprofile-info-section
- run an app on an embedded system and do a memory dump to a
terminal/console
- take the memory dump to a host system (with IO), run
__gcov_init_from_memory_dump (...)
and then do a normal __gcov_dump
I am not sure if a plain memory dump really simplifies things. You have
to get the filename separately since it is only referenced in gcov_info
and not included in the structure:
struct gcov_info
{
[...]
const char *filename; /* output file name */
[...]
#ifndef IN_GCOV_TOOL
const struct gcov_fn_info *const *functions; /* pointer to pointers
to function
information */
[...]
#endif /* !IN_GCOV_TOOL */
};
Also the gcov_fn_info is not embedded in the gcov_info structure. If you
do a plain memory dump, then you dump also pointers and how do you deal
with these pointers on the host? You would need some extra information
to describe the memory dump. So, why not use the gcda format for this?
It is also more compact since zero value counters are skipped. Serial
lines are slow, so less data to transfer is good.
/* Convert the gcov information to a gcda data stream. The first
callback is
called exactly once with the filename associated with the gcov
information.
The filename may be NULL. Afterwards, the second callback is
subsequently
called with chunks (the begin and length of the chunk are passed as the
first two arguments) of the gcda data stream. The fourth parameter is a
user-provided argument passed as the last argument to the callback
functions. */
extern void __gcov_info_to_gcda (const struct gcov_info *gi_ptr,
void (*filename) (const char *name, void *arg),
void (*dump) (const void *begin, unsigned size, void
*arg),
void *arg);
If __gcov_info_to_gcda() is correctly implemented, then this should give
you directly gcda files if you use something like this:
#include
#include
extern const struct gcov_info *__gcov_info_start[];
extern const struct gcov_info *__gcov_info_end[];
static void
filename (const char *f, void *arg)
{
FILE **file = arg;
*file = fopen(f, "rb");
}
static void
dump (const void *d, unsigned n, void *arg)
{
FILE **file = arg;
fwrite(d, n, 1, *file);
}
static void
dump_gcov_info (void)
{
const struct gcov_info **info = __gcov_info_start;
const struct gcov_info **end = __gcov_info_end;
/* Obfuscate variable to prevent compiler optimizations. */
__asm__ ("" : "+r" (end));
while (info != end)
{
FILE *file = NULL;
__gcov_info_to_gcda (*info, filename, dump, );
fclose(file);
++info;
}
}
int
main()
{
dump_gcov_info();
return 0;
}
The callback functions give the user the full control how the data of
the gcda file is encoded for the transfer to a host. No gcov internals
are exposed.
--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@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/
Re: [PATCH] gcov: Add __gcov_info_to_gdca()
On 11/17/20 10:57 AM, Sebastian Huber wrote:
This is a proposal to get the gcda data for a gcda info in a free-standing
environment. It is intended to be used with the -fprofile-info-section option.
A crude test program which doesn't use a linker script is:
Hello.
I'm not pretty sure how this set up is going to work. Can you please explain me
that?
I was thinking about your needs and I can imagine various techniques how to
generate
gcda files format:
1) embedded system can override fopen, fwrite, fseek to a functions that do a
remote
write-related functions
2) - use -fprofile-info-section
- run an app on an embedded system and do a memory dump to a terminal/console
- take the memory dump to a host system (with IO), run
__gcov_init_from_memory_dump (...)
and then do a normal __gcov_dump
What do you think about it?
Btw. I'm planning to commit in next stage1 removal of the internal I/O
buffering.
Martin
>From 5a17015c096012b9e43a8dd45768a8d5fb3a3aee Mon Sep 17 00:00:00 2001
From: marxin
Date: Wed, 18 Nov 2020 16:13:23 +0100
Subject: [PATCH] gcov: Use system IO buffering
gcc/ChangeLog:
* gcov-io.c (gcov_write_block): Remove.
(gcov_write_words): Likewise.
(gcov_read_words): Re-implement using gcov_read_bytes.
(gcov_allocate): Remove.
(GCOV_BLOCK_SIZE): Likewise.
(struct gcov_var): Remove most of the fields.
(gcov_position): Implement with ftell.
(gcov_rewrite): Remove setting of start and offset fields.
(from_file): Re-format.
(gcov_open): Remove setbuf call. It should not be needed.
(gcov_close): Remove internal buffer handling.
(gcov_magic): Use __builtin_bswap32.
(gcov_write_counter): Use directly gcov_write_unsigned.
(gcov_write_string): Use direct fwrite and do not round
to 4 bytes.
(gcov_seek): Use directly fseek.
(gcov_write_tag): Use gcov_write_unsigned directly.
(gcov_write_length): Likewise.
(gcov_write_tag_length): Likewise.
(gcov_read_bytes): Use directly fread.
(gcov_read_unsigned): Use gcov_read_words.
(gcov_read_counter): Likewise.
(gcov_read_string): Use gcov_read_bytes.
* gcov-io.h (GCOV_WORD_SIZE): Adjust to reflect
that size is not in bytes, not words (4B).
(GCOV_TAG_FUNCTION_LENGTH): Likewise.
(GCOV_TAG_ARCS_LENGTH): Likewise.
(GCOV_TAG_ARCS_NUM): Likewise.
(GCOV_TAG_COUNTER_LENGTH): Likewise.
(GCOV_TAG_COUNTER_NUM): Likewise.
(GCOV_TAG_SUMMARY_LENGTH): Likewise.
libgcc/ChangeLog:
* libgcov-driver.c: Fix GNU coding style.
---
gcc/gcov-io.c | 282 +---
gcc/gcov-io.h | 17 ++-
libgcc/libgcov-driver.c | 2 +-
3 files changed, 75 insertions(+), 226 deletions(-)
diff --git a/gcc/gcov-io.c b/gcc/gcov-io.c
index 4db56f8aacf..c3ca404f8b5 100644
--- a/gcc/gcov-io.c
+++ b/gcc/gcov-io.c
@@ -27,40 +27,14 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
/* Routines declared in gcov-io.h. This file should be #included by
another source file, after having #included gcov-io.h. */
-#if !IN_GCOV
-static void gcov_write_block (unsigned);
-static gcov_unsigned_t *gcov_write_words (unsigned);
-#endif
-static const gcov_unsigned_t *gcov_read_words (unsigned);
-#if !IN_LIBGCOV
-static void gcov_allocate (unsigned);
-#endif
-
-/* Optimum number of gcov_unsigned_t's read from or written to disk. */
-#define GCOV_BLOCK_SIZE (1 << 10)
+static gcov_unsigned_t *gcov_read_words (void *buffer, unsigned);
struct gcov_var
{
FILE *file;
- gcov_position_t start; /* Position of first byte of block */
- unsigned offset; /* Read/write position within the block. */
- unsigned length; /* Read limit in the block. */
- unsigned overread; /* Number of words overread. */
int error; /* < 0 overflow, > 0 disk error. */
- int mode; /* < 0 writing, > 0 reading */
+ int mode; /* < 0 writing, > 0 reading */
int endian; /* Swap endianness. */
-#if IN_LIBGCOV
- /* Holds one block plus 4 bytes, thus all coverage reads & writes
- fit within this buffer and we always can transfer GCOV_BLOCK_SIZE
- to and from the disk. libgcov never backtracks and only writes 4
- or 8 byte objects. */
- gcov_unsigned_t buffer[GCOV_BLOCK_SIZE + 1];
-#else
- /* Holds a variable length block, as the compiler can write
- strings and needs to backtrack. */
- size_t alloc;
- gcov_unsigned_t *buffer;
-#endif
} gcov_var;
/* Save the current position in the gcov file. */
@@ -71,8 +45,7 @@ static inline
gcov_position_t
gcov_position (void)
{
- gcov_nonruntime_assert (gcov_var.mode > 0);
- return gcov_var.start + gcov_var.offset;
+ return ftell (gcov_var.file);
}
/* Return nonzero if the error flag is set. */
@@ -92,20 +65,16 @@ GCOV_LINKAGE inline void
gcov_rewrite (void)
{
gcov_var.mode = -1;
- gcov_var.start = 0;
- gcov_var.offset = 0;
fseek (gcov_var.file, 0L, SEEK_SET);
}
#endif
-static inline gcov_unsigned_t from_file (gcov_unsigned_t value)
+static inline gcov_unsigned_t
+from_file (gcov_unsigned_t value)
[PATCH] gcov: Add __gcov_info_to_gdca()
This is a proposal to get the gcda data for a gcda info in a free-standing
environment. It is intended to be used with the -fprofile-info-section option.
A crude test program which doesn't use a linker script is:
#include
#include
extern const struct gcov_info *my_info;
static void
filename(const char *f, void *arg)
{
printf("filename: %s\n", f);
}
static void
dump(const void *d, unsigned n, void *arg)
{
const unsigned char *c;
unsigned i;
c = d;
for (i = 0; i < n; ++i) {
printf("%02x", c[i]);
}
}
int main()
{
__asm__ volatile (".set my_info, .LPBX2");
__gcov_info_to_gcda(my_info, filename, dump, NULL);
return 0;
}
gcc/
* doc/invoke.texi (fprofile-info-section): Mention
__gcov_info_to_gdca().
libgcc/
Makefile.in (LIBGCOV_DRIVER): Add _gcov_info_to_gcda.
gcov.h (gcov_info): Declare.
(__gcov_info_to_gdca): Likewise.
libgcov-driver.c (gcov_are_all_counters_zero): New.
(write_one_data): Use gcov_are_all_counters_zero().
(gcov_fn_info_to_gcda): New.
(__gcov_info_to_gcda): Likewise.
---
gcc/doc/invoke.texi | 73
libgcc/Makefile.in | 2 +-
libgcc/gcov.h | 15 +
libgcc/libgcov-driver.c | 120
4 files changed, 188 insertions(+), 22 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 3510a54c6c4..09cb4922f5e 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -14248,17 +14248,17 @@ To optimize the program based on the collected
profile information, use
Register the profile information in the specified section instead of using a
constructor/destructor. The section name is @var{name} if it is specified,
otherwise the section name defaults to @code{.gcov_info}. A pointer to the
-profile information generated by @option{-fprofile-arcs} or
-@option{-ftest-coverage} is placed in the specified section for each
-translation unit. This option disables the profile information registration
-through a constructor and it disables the profile information processing
-through a destructor. This option is not intended to be used in hosted
-environments such as GNU/Linux. It targets systems with limited resources
-which do not support constructors and destructors. The linker could collect
-the input sections in a continuous memory block and define start 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. A
-GNU linker script example which defines a linker output section follows:
+profile information generated by @option{-fprofile-arcs} is placed in the
+specified section for each translation unit. This option disables the profile
+information registration through a constructor and it disables the profile
+information processing through a destructor. This option is not intended to be
+used in hosted environments such as GNU/Linux. It targets free-standing
+environments (for example embedded systems) with limited resources which do not
+support constructors/destructors or the C library file I/O.
+
+The linker could collect the input sections in a continuous memory block and
+define start and end symbols. A GNU linker script example which defines a
+linker output section follows:
@smallexample
.gcov_info :
@@ -14269,6 +14269,57 @@ GNU linker script example which defines a linker
output section follows:
@}
@end smallexample
+The program could dump the profiling information registered in this linker set
+for example like this:
+
+@smallexample
+#include
+#include
+
+extern const struct gcov_info *__gcov_info_start[];
+extern const struct gcov_info *__gcov_info_end[];
+
+static void
+filename (const char *f, void *arg)
+@{
+ puts (f);
+@}
+
+static void
+dump (const void *d, unsigned n, void *arg)
+@{
+ const unsigned char *c = d;
+
+ for (unsigned i = 0; i < n; ++i)
+printf ("%02x", c[i]);
+@}
+
+static void
+dump_gcov_info (void)
+@{
+ const struct gcov_info **info = __gcov_info_start;
+ const struct gcov_info **end = __gcov_info_end;
+
+ /* Obfuscate variable to prevent compiler optimizations. */
+ __asm__ ("" : "+r" (end));
+
+ while (info != end)
+ @{
+void *arg = NULL;
+__gcov_info_to_gcda (*info, filename, dump, arg);
+putchar ('\n');
+++info;
+ @}
+@}
+
+int
+main()
+@{
+ dump_gcov_info();
+ return 0;
+@}
+@end smallexample
+
@item -fprofile-note=@var{path}
@opindex fprofile-note
diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
index d6075d32bd4..c22413d768c 100644
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -908,7 +908,7 @@ LIBGCOV_INTERFACE = _gcov_dump _gcov_fork
\
_gcov_execl _gcov_execlp\
_gcov_execle _gcov_execv _gcov_execvp _gcov_execve _gcov_reset \
