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,
Christophe Guillon <christophe.guillon@st.com>,
rusty@rustcorp.com.au, linux-arch@vger.kernel.org, arnd@arndb.de,
mgahagan@redhat.com, agospoda@redhat.com
Subject: Re: [RFC PATCH 0/4] add support for gcov format introduced in gcc 4.7
Date: Mon, 26 Aug 2013 13:57:03 +0200 [thread overview]
Message-ID: <521B428F.6020801@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130823161532.GA2336@localhost.localdomain>
On 23.08.2013 18:15, Frantisek Hrbata wrote:
> On Fri, Aug 23, 2013 at 05:08:07PM +0200, Peter Oberparleiter wrote:
>> Most of your code looks very familiar. There's one feature missing though
>> that Christophe brought up as a requirement: the ability for gcov-kernel
>> to cope with kernel modules being compiled with GCC versions implementing
>> a different gcov format (apparently this can happen in some embedded
>> setups).
>
> Here follows quote from the gcc/gcov-io.h file
>
> <quote>
> Coverage information is held in two files. A notes file, which is
> generated by the compiler, and a data file, which is generated by
> the program under test. Both files use a similar structure. We do
> not attempt to make these files backwards compatible with previous
> versions, as you only need coverage information when developing a
> program. We do hold version information, so that mismatches can be
> detected, and we use a format that allows tools to skip information
> they do not understand or are not interested in.
> </quote>
>
> Also from my experience, I would expect that the gcov will be used during
> development, meaning re-compilation isn't a big problem here. I for sure can be
> missing something and I'm by no means saying it wouldn't be useful feature. Just
> that it would complite things a little bit.
Here's the info I got from Christophe when we last discussed this feature:
"The main issue is compilation of modules with a different
compiler from the kernel. It is a quite common situation in embedded
Linuxes, as modules can be published far after the core kernel, thus
for our use it is a good feature."
I'd say that if we can support that setup with manageable extra effort,
it would be worth it.
>> Christophe proposed run-time version checking and a file-ops type function
>> table which is chosen based on info->version. I found this approach
>> somewhat intrusive and this would also not have covered the case where a
>> new GCC versions was used to compile kernel modules for which the base
>> kernel has no support. I tried to solve this requirement by combining
>> two changes:
>>
>> 1) make the gcov-format generated by gcov-kernel compile-time configurable
>> 2) separate the gcov-format specific code into a loadable kernel module
>
> So if I understand it correctly you would separate the input
> format(gcov_info) from the output(gcda files). Meaning no matter which gcc
> compiled the module you can select the gcda format. And even if the kernel does
> not know the new format you can simply compile a module supporting it, instead
> of the whole kernel.
Actually my proposal is far simpler:
- the gcov-kernel module supports one GCC format (both gcov_info as well as .gcda)
- the module can be recompiled with different format support
- it will create correct .gcda files for all object files compiled with a
compatible compiler
- for other object files, either the resulting .gcda files are unusable or no
.gcda file would be registered at all (based on info->version differences),
though that would raise the question on how to handle older GCC versions
into which the new gcov format code was integrated
> Can you please give me an example why this is needed? As I wrote I'm not that
> familiar with gcov and I'm probably missing something, but I do not understand
> why this(handling several versions at runtime, not only the one used by gcc
> during compilation) is useful(note my comment above about the gcov used during
> development).
See note above from Christophe: kernel and module are compiled by different parties
at different times using different GCC versions, and apparently the production kernel
has gcov support enabled or they are providing a separate test kernel for that.
Regards,
Peter
--
Peter Oberparleiter
Linux on System z Development - IBM Germany
prev parent reply other threads:[~2013-08-26 11:57 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
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 [this message]
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=521B428F.6020801@linux.vnet.ibm.com \
--to=oberpar@linux.vnet.ibm.com \
--cc=agospoda@redhat.com \
--cc=arnd@arndb.de \
--cc=christophe.guillon@st.com \
--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.