linux-arch.vger.kernel.org archive mirror
 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

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

Thread overview: 44+ 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  8:39   ` Frantisek Hrbata
2013-08-23 15:09   ` Peter Oberparleiter
2013-08-23 15:09     ` Peter Oberparleiter
2013-08-23 16:50     ` Frantisek Hrbata
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  8:39   ` 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-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  8:39   ` 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-28 13:54                 ` Frantisek Hrbata
2013-08-24 19:12     ` Frantisek Hrbata
2013-08-24 19:12       ` Frantisek Hrbata
2013-08-26 12:56       ` Peter Oberparleiter
2013-08-26 12:56         ` Peter Oberparleiter
2013-08-27 13:23         ` Frantisek Hrbata
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  8:39   ` 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-23 16:15     ` Frantisek Hrbata
2013-08-26 11:39     ` LF.Tan
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 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 NNTP newsgroup(s).