I don't understand why static variables can cause any safety issue in
multi-thread programs.
For any process, gcov_dump will be called only once and there will be
one instance of globals.
(v)fork, failing exec and other cases can lead to gcov_flush being called
several times and that calls
On Wed, Jan 8, 2014 at 2:33 PM, Rong Xu x...@google.com wrote:
On Fri, Dec 6, 2013 at 6:23 AM, Jan Hubicka hubi...@ucw.cz wrote:
@@ -325,6 +311,9 @@ static struct gcov_summary all_prg;
#endif
/* crc32 for this program. */
static gcov_unsigned_t crc32;
+/* Use this summary checksum rather
My bad.
Thanks for the fix!
-Rong
On Thu, Jan 9, 2014 at 11:47 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Jan 8, 2014 at 2:33 PM, Rong Xu x...@google.com wrote:
On Fri, Dec 6, 2013 at 6:23 AM, Jan Hubicka hubi...@ucw.cz wrote:
@@ -325,6 +311,9 @@ static struct gcov_summary all_prg;
Here is the patch that addresses Honza's concern about bss increment.
It just makes this_prg a local variable.
Some comments are inlined.
On Fri, Dec 6, 2013 at 6:23 AM, Jan Hubicka hubi...@ucw.cz wrote:
Do you know how the size of libgcov changed with your patch?
Quick check of current
On Wed, Dec 18, 2013 at 9:28 AM, Xinliang David Li davi...@google.com wrote:
#ifdef L_gcov_merge_ior
/* The profile merging function that just adds the counters. It is given
- an array COUNTERS of N_COUNTERS old counters and it reads the same
number
- of counters from the gcov file.
On Fri, Dec 6, 2013 at 6:23 AM, Jan Hubicka hubi...@ucw.cz wrote:
@@ -325,6 +311,9 @@ static struct gcov_summary all_prg;
#endif
/* crc32 for this program. */
static gcov_unsigned_t crc32;
+/* Use this summary checksum rather the computed one if the value is
+ *non-zero. */
+static
On Wed, Jan 8, 2014 at 2:20 PM, Rong Xu x...@google.com wrote:
On Wed, Dec 18, 2013 at 9:28 AM, Xinliang David Li davi...@google.com wrote:
#ifdef L_gcov_merge_ior
/* The profile merging function that just adds the counters. It is given
- an array COUNTERS of N_COUNTERS old counters and
#ifdef L_gcov_merge_ior
/* The profile merging function that just adds the counters. It is given
- an array COUNTERS of N_COUNTERS old counters and it reads the same number
- of counters from the gcov file. */
+ an array COUNTERS of N_COUNTERS old counters.
+ When SRC==NULL, it
On Mon, Dec 16, 2013 at 2:48 PM, Xinliang David Li davi...@google.com wrote:
Ok -- gcov_write_counter and gcov_write_tag_length are qualified as
low level primitives for basic gcov format and probably should be kept
in gcov-io.c.
gcov_rewrite is petty much libgcov runtime implementation
On Tue, Dec 17, 2013 at 7:48 AM, Teresa Johnson tejohn...@google.com wrote:
On Mon, Dec 16, 2013 at 2:48 PM, Xinliang David Li davi...@google.com wrote:
Ok -- gcov_write_counter and gcov_write_tag_length are qualified as
low level primitives for basic gcov format and probably should be kept
in
gcov_rewrite function is only needed (and defined) with IN_LIBGCOV.
Should it be moved from common file gcov-io.c to libgcov.c?
David
On Thu, Dec 12, 2013 at 12:11 PM, Teresa Johnson tejohn...@google.com wrote:
On Wed, Dec 11, 2013 at 10:05 PM, Teresa Johnson tejohn...@google.com wrote:
On
On Mon, Dec 16, 2013 at 12:55 PM, Xinliang David Li davi...@google.com wrote:
gcov_rewrite function is only needed (and defined) with IN_LIBGCOV.
Should it be moved from common file gcov-io.c to libgcov.c?
Possibly. I just looked through gcov-io.c and there are several
additional functions that
I think so -- they are private to libgcov. Honza, what do you think?
thanks,
David
On Mon, Dec 16, 2013 at 1:17 PM, Teresa Johnson tejohn...@google.com wrote:
On Mon, Dec 16, 2013 at 12:55 PM, Xinliang David Li davi...@google.com
wrote:
gcov_rewrite function is only needed (and defined)
I think so -- they are private to libgcov. Honza, what do you think?
Hmm, the purpose of gcov-io was to be low level IO library for the basic
gcov file format. I am not sure if gcov_write_tag_length should really resist
in other file than gcov_write_tag.
I see a desire to isolate actual stdio
Ok -- gcov_write_counter and gcov_write_tag_length are qualified as
low level primitives for basic gcov format and probably should be kept
in gcov-io.c.
gcov_rewrite is petty much libgcov runtime implementation details so I
think it should be moved out. gcov_write_summary is not related to
gcov
On Wed, Dec 11, 2013 at 10:05 PM, Teresa Johnson tejohn...@google.com wrote:
On Fri, Dec 6, 2013 at 6:23 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi, all
This is the new patch for gcov-tool (previously profile-tool).
Honza: can you comment on the new merge interface? David posted some
comments
On Fri, Dec 6, 2013 at 6:23 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi, all
This is the new patch for gcov-tool (previously profile-tool).
Honza: can you comment on the new merge interface? David posted some
comments in an earlier email and we want to know what's your opinion.
Test patch has
I agree with the staged checkin plan proposed. Teresa, can you help
with spliting out the libgcov.h/gcov-io.h change out (Rong is on a
trip..)
thanks,
David
On Fri, Dec 6, 2013 at 6:23 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi, all
This is the new patch for gcov-tool (previously
On Tue, Dec 10, 2013 at 11:01 AM, Xinliang David Li davi...@google.com wrote:
I agree with the staged checkin plan proposed. Teresa, can you help
with spliting out the libgcov.h/gcov-io.h change out (Rong is on a
trip..)
Sure, I will work on that part and send a patch once it is tested.
Hi, all
This is the new patch for gcov-tool (previously profile-tool).
Honza: can you comment on the new merge interface? David posted some
comments in an earlier email and we want to know what's your opinion.
Test patch has been tested with boostrap, regresssion,
profiledbootstrap and
Ping.
On Mon, Nov 18, 2013 at 12:31 PM, Xinliang David Li davi...@google.com wrote:
gcov-dump tool does raw dump of profile data. In the long run, we
should have only one gcov profile manipulation tool, so it might be
better to incorporate gcov-dump into gcov-tool and get rid of
'gcov-dump'.
gcov-dump tool does raw dump of profile data. In the long run, we
should have only one gcov profile manipulation tool, so it might be
better to incorporate gcov-dump into gcov-tool and get rid of
'gcov-dump'.
David
On Mon, Nov 18, 2013 at 12:24 PM, Rong Xu x...@google.com wrote:
Hi, all
This
The patch was checked in as r204730.
Tested with
configure with --enable-languages=all,obj-c++
(ada is currently broken, so I was not be able test)
bootstrap and profiledbootstrap
regression for -m32 and -m64.
spec2006
The only semantic change is __gcov_flush() used to be under L_gcov.
I put the
2013-11-04 Rong Xu x...@google.com
* libgcc/libgcov.c: Delete as part of re-factoring.
* libgcc/libgcov-profiler.c (__gcov_interval_profiler): Moved from
libgcov.c
(__gcov_pow2_profiler): Ditto.
(__gcov_one_value_profiler_body): Ditto.
Here is the patch that includes profile-tool.
Profile-tool now has two functions: merge and rewrite. I'll add diff later.
Compiler is tested with spec2006 and profiledbootstrap.
profile-tool is tested with spec2006 profiles.
Hi,
it would be nice if you could elaborate bit more on the tool
On Mon, Nov 11, 2013 at 7:02 AM, Jan Hubicka hubi...@ucw.cz wrote:
2013-11-04 Rong Xu x...@google.com
* libgcc/libgcov.c: Delete as part of re-factoring.
* libgcc/libgcov-profiler.c (__gcov_interval_profiler): Moved from
libgcov.c
(__gcov_pow2_profiler): Ditto.
On Mon, Nov 11, 2013 at 7:17 AM, Jan Hubicka hubi...@ucw.cz wrote:
Here is the patch that includes profile-tool.
Profile-tool now has two functions: merge and rewrite. I'll add diff later.
Compiler is tested with spec2006 and profiledbootstrap.
profile-tool is tested with spec2006 profiles.
in libgcov-driver.c
/* Flag when the profile has already been dumped via __gcov_dump(). */
static int gcov_dump_complete;
inline void
set_gcov_dump_complete (void)
{
gcov_dump_complete = 1;
}
inline void
reset_gcov_dump_complete (void)
{
gcov_dump_complete = 0;
}
These should be
On Fri, Nov 8, 2013 at 10:22 AM, Xinliang David Li davi...@google.com wrote:
in libgcov-driver.c
/* Flag when the profile has already been dumped via __gcov_dump(). */
static int gcov_dump_complete;
inline void
set_gcov_dump_complete (void)
{
gcov_dump_complete = 1;
}
inline void
1) I don't think you need in_mem flag. For in memory merge, the source !=
NULL.
discard this comment.
David
On Thu, Nov 7, 2013 at 3:34 PM, Rong Xu x...@google.com wrote:
On Thu, Nov 7, 2013 at 9:40 AM, Joseph S. Myers jos...@codesourcery.com
wrote:
On Thu, 7 Nov 2013, Rong Xu
A question about inhibit_libc.
When inhibit_libc is defined, we provide dummy functions for all the
__gcov_* methods.
Is it purposely to minimize the footprint?
I'm thinking to allow some codes that are independent of libc (and its
headers) under this. Is it OK?
-Rong
On Fri, Nov 8, 2013 at
On Fri, Nov 8, 2013 at 10:48 AM, Rong Xu x...@google.com wrote:
On Fri, Nov 8, 2013 at 10:22 AM, Xinliang David Li davi...@google.com wrote:
in libgcov-driver.c
/* Flag when the profile has already been dumped via __gcov_dump(). */
static int gcov_dump_complete;
inline void
On Fri, Nov 8, 2013 at 10:56 AM, Rong Xu x...@google.com wrote:
A question about inhibit_libc.
When inhibit_libc is defined, we provide dummy functions for all the
__gcov_* methods.
Is it purposely to minimize the footprint?
I'm thinking to allow some codes that are independent of libc (and
On Fri, Nov 8, 2013 at 11:02 AM, Xinliang David Li davi...@google.com wrote:
On Fri, Nov 8, 2013 at 10:48 AM, Rong Xu x...@google.com wrote:
On Fri, Nov 8, 2013 at 10:22 AM, Xinliang David Li davi...@google.com
wrote:
in libgcov-driver.c
/* Flag when the profile has already been dumped via
On Fri, Nov 8, 2013 at 11:21 AM, Rong Xu x...@google.com wrote:
On Fri, Nov 8, 2013 at 11:02 AM, Xinliang David Li davi...@google.com wrote:
On Fri, Nov 8, 2013 at 10:48 AM, Rong Xu x...@google.com wrote:
On Fri, Nov 8, 2013 at 10:22 AM, Xinliang David Li davi...@google.com
wrote:
in
On Fri, Nov 8, 2013 at 11:30 AM, Xinliang David Li davi...@google.com wrote:
On Fri, Nov 8, 2013 at 11:21 AM, Rong Xu x...@google.com wrote:
On Fri, Nov 8, 2013 at 11:02 AM, Xinliang David Li davi...@google.com
wrote:
On Fri, Nov 8, 2013 at 10:48 AM, Rong Xu x...@google.com wrote:
On Fri,
On Fri, 8 Nov 2013, Rong Xu wrote:
A question about inhibit_libc.
When inhibit_libc is defined, we provide dummy functions for all the
__gcov_* methods.
Is it purposely to minimize the footprint?
inhibit_libc is for use in bootstrap builds when libc headers aren't
available - for building
On Thu, 7 Nov 2013, Rong Xu wrote:
Thanks Joseph for these detailed comments/suggestions.
The fixed patch is attached to this email.
The only thing left out is the Texinfo manual. Do you mean this tool
should have its it's own texi file in gcc/doc?
Its own texi file, probably included as a
I have not looked this in detail, but it looks like the copy right
header of the new file is wrong (including the year).
You should 1) document the command line syntax somewhere, possibly in
comment? 2) add a help command for the tool to dump out help message.
David
On Wed, Nov 6, 2013 at 1:25
On Wed, 6 Nov 2013, Rong Xu wrote:
In current implementation, if you use 'profile-tool help', it will
print out the usage and exit.
Please make sure you follow the GNU Coding Standards. Any installed tool
needs to support --help, with output following the GNU Coding Standards,
to standard
I wonder if it makes sense to get rid of the conditional compile such as
#ifdef L_gcov_x
..
#endif
This has the advantage of producing slightly smaller instrumented
binary, but this benefit can also be achieved via -ffunction-sections
and let linker to garbage collect unused
On Tue, Nov 05, 2013 at 10:18:50AM +0100, Jan Hubicka wrote:
I wonder if it makes sense to get rid of the conditional compile such as
#ifdef L_gcov_x
..
#endif
This has the advantage of producing slightly smaller instrumented
binary, but this benefit can also be achieved
Those functions are not referencing each other, but they get used in
different logical groups, so at least control granularity can be
improved. For instance,
1) all gcov user interfaces such as gcov_dump, gcov_flush, gcov_reset
are either not used at all, or all of them are used -- there is no
Thanks! Can you attach the patch file for the proposed change?
David
On Fri, Nov 1, 2013 at 2:08 PM, Rong Xu x...@google.com wrote:
libgcov.c is the main file to generate libgcov.a. This single source
generates
21 object files and then archives to a library. These objects are of
BTW, this part of patch only does the re-factoring work.
I haven't finished the porting of profile-tool part of patch to the
trunk. They should be in a separate patch anyway.
-Rong
On Mon, Nov 4, 2013 at 2:43 PM, Rong Xu x...@google.com wrote:
Honza, Thanks for the comments!
Attached is the
On Mon, Nov 4, 2013 at 2:43 PM, Rong Xu x...@google.com wrote:
Honza, Thanks for the comments!
Attached is the patch.
Passed spec2006 fdo build and profiledbootstrap in gcc.
I'm doing some other tests.
-Rong
On Mon, Nov 4, 2013 at 1:55 AM, Jan Hubicka hubi...@ucw.cz wrote:
Thanks! Can you
I wonder if it makes sense to get rid of the conditional compile such as
#ifdef L_gcov_x
..
#endif
This has the advantage of producing slightly smaller instrumented
binary, but this benefit can also be achieved via -ffunction-sections
and let linker to garbage collect unused functions.
Thanks! Can you attach the patch file for the proposed change?
David
On Fri, Nov 1, 2013 at 2:08 PM, Rong Xu x...@google.com wrote:
libgcov.c is the main file to generate libgcov.a. This single source generates
21 object files and then archives to a library. These objects are of
very
libgcov.c is the main file to generate libgcov.a. This single source generates
21 object files and then archives to a library. These objects are of
very different purposes but they are in the same file guarded by various macros.
The source file becomes quite large and its readability becomes very
49 matches
Mail list logo
