All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
To: Frantisek Hrbata <fhrbata@redhat.com>
Cc: linux-kernel@vger.kernel.org, jstancek@redhat.com,
	keescook@chromium.org, rusty@rustcorp.com.au,
	linux-arch@vger.kernel.org, arnd@arndb.de, mgahagan@redhat.com,
	agospoda@redhat.com
Subject: Re: [RFC PATCH 1/4] gcov: move gcov structs definitions to a gcc version specific file
Date: Mon, 26 Aug 2013 14:17:37 +0200	[thread overview]
Message-ID: <521B4761.9010706@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130823165045.GB2336@localhost.localdomain>

On 23.08.2013 18:50, Frantisek Hrbata wrote:
> On Fri, Aug 23, 2013 at 05:09:58PM +0200, Peter Oberparleiter wrote:
>> On 23.08.2013 10:39, Frantisek Hrbata wrote:
>>> Since also the gcov structures(gcov_info, gcov_fn_info, gcov_ctr_info) can
>>> change between gcc releases, as shown in gcc 4.7, they cannot be defined in a
>>> common header and need to be moved to a specific gcc implemention file. This
>>> also requires to make the gcov_info structure opaque for the common code and to
>>> introduce simple helpers for accessing data inside gcov_info.
>>
>> I've taken a similar approach in my version, although I stopped at isolating
>> the code that handles the linked list. I like your version better since it's
>> more consistent.
> 
> :) I also have doubts with the list "abstraction", it isn't very nice. I tried
> to keep the changes as simple as possible in the generic code. I'm not sayint it
> is the right approach, but your design is pretty good, so I had no urges to
> change it more deeper. I'm of course open to any suggestions.

I'd say go for this approach while it works and consider a replacement when it
becomes necessary (because only then do we know what the requirements will be).

>>> diff --git a/kernel/gcov/gcc_3_4.c b/kernel/gcov/gcc_3_4.c
>>> index ae5bb42..27bc88a 100644
>>> --- a/kernel/gcov/gcc_3_4.c
>>> +++ b/kernel/gcov/gcc_3_4.c
>>> @@ -21,6 +21,121 @@
>>>  #include <linux/vmalloc.h>
>>>  #include "gcov.h"
>>>
>>> +#define GCOV_COUNTERS		5
>>
>> The value for GCOV_COUNTERS has been changed with GCC 4.3. Before it was 5,
>> starting with GCC 4.3 the value is 8. While this is not strictly necessary, I'm
>> wondering if this should be added here to prevent any unwanted side-effects.
> 
> Yes I was thinking about this two. My first idea was to use some define, maybe
> in the Makefile during the gcc version check and set the number of counters
> properly later based on this define. Something like
> 
> #if GCOV_GCC_VERIONS >= 0430
> #define GCOV_COUNTERS 8
> #elif ...
> 
> for the gcc_3_4.c implementation.
> 
> But I'm not sure what the new counters are good for and if they are really
> needed for the coverage info. This would require deeper understanding what
> and how the types of counters are used. At this point a simply did not change the
> value for the format before gcc 4.7, because each counter type has a tag and
> this should be backward compatible. We only miss the new counters. Again this is
> something that probably deserves more attention. Thanks for pointing this out!

Starting with GCC 4.7 support, GCOV_COUNTERS will have a direct effect on the
size of gcov_info, so an incorrect value will break the format code. The change
I commented on was pre-4.7 code though, so its not that important there. On the
other hand it could help to have a corresponding mechanism in place once
GCOV_COUNTERS changes again. Maybe something like a macro to determine if GCC
is below a certain level.


Regards,
  Peter

-- 
Peter Oberparleiter
Linux on System z Development - IBM Germany

  reply	other threads:[~2013-08-26 12:17 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-23  8:39 [RFC PATCH 0/4] add support for gcov format introduced in gcc 4.7 Frantisek Hrbata
2013-08-23  8:39 ` [RFC PATCH 1/4] gcov: move gcov structs definitions to a gcc version specific file Frantisek Hrbata
2013-08-23 15:09   ` Peter Oberparleiter
2013-08-23 16:50     ` Frantisek Hrbata
2013-08-26 12:17       ` Peter Oberparleiter [this message]
2013-08-23  8:39 ` [RFC PATCH 2/4] gcov: add support for gcc 4.7 gcov format Frantisek Hrbata
2013-08-23 15:12   ` Peter Oberparleiter
2013-08-23 21:00     ` Frantisek Hrbata
2013-08-26 12:45       ` Peter Oberparleiter
2013-08-27 13:41         ` Frantisek Hrbata
2013-08-23  8:39 ` [RFC PATCH 3/4] gcov: compile specific gcov implementation based on gcc version Frantisek Hrbata
2013-08-23 15:15   ` Peter Oberparleiter
2013-08-23 15:21     ` Peter Oberparleiter
2013-08-24 19:44       ` Frantisek Hrbata
2013-08-25 18:29         ` Arnd Bergmann
2013-08-26 14:14         ` Peter Oberparleiter
2013-08-27 13:34           ` Frantisek Hrbata
2013-08-28 13:46             ` Peter Oberparleiter
2013-08-28 13:54               ` Frantisek Hrbata
2013-08-24 19:12     ` Frantisek Hrbata
2013-08-26 12:56       ` Peter Oberparleiter
2013-08-27 13:23         ` Frantisek Hrbata
2013-08-23  8:39 ` [RFC PATCH 4/4] kernel: add support for init_array constructors Frantisek Hrbata
2013-08-23 15:13   ` Peter Oberparleiter
2013-08-23 16:55     ` Frantisek Hrbata
2013-08-23 15:08 ` [RFC PATCH 0/4] add support for gcov format introduced in gcc 4.7 Peter Oberparleiter
2013-08-23 16:15   ` Frantisek Hrbata
2013-08-26 11:39     ` LF.Tan
2013-08-26 14:19       ` Peter Oberparleiter
2013-08-27  2:38         ` LF.Tan
2013-08-26 11:57     ` Peter Oberparleiter

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=521B4761.9010706@linux.vnet.ibm.com \
    --to=oberpar@linux.vnet.ibm.com \
    --cc=agospoda@redhat.com \
    --cc=arnd@arndb.de \
    --cc=fhrbata@redhat.com \
    --cc=jstancek@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgahagan@redhat.com \
    --cc=rusty@rustcorp.com.au \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.