On Wed, Aug 28, 2013 at 03:46:05PM +0200, Peter Oberparleiter wrote: > On 27.08.2013 15:34, Frantisek Hrbata wrote: > > On Mon, Aug 26, 2013 at 04:14:07PM +0200, Peter Oberparleiter wrote: > >> On 24.08.2013 21:44, Frantisek Hrbata wrote: > >>> On Fri, Aug 23, 2013 at 05:21:12PM +0200, Peter Oberparleiter wrote: > >>>> On 23.08.2013 17:15, Peter Oberparleiter wrote: > >>>>> On 23.08.2013 10:39, Frantisek Hrbata wrote: > >>>>>> Compile the correct gcov implementation file for a specific gcc > >>>>>> version. In > >>>>>> the future, if another file is added, the conditions will need to be > >>>>>> somehow > >>>>>> adjusted to if-elif-else case, but at this point the simple > >>>>>> cc-ifversion should > >>>>>> be enough. > >>>> > >>>> As promised, I'm also adding the patch that makes the format-specific > >>>> part > >>>> of gcov-kernel a loadable kernel module: > >>>> > >>>> --- > >>>> kernel: gcov: make format-specific code loadable > >>>> > >>>> Turn the format-specific part of gcov-kernel into a loadable kernel > >>>> module. This enables the use of gcov-kernel with kernel modules > >>>> that were compiled with a version of GCC that produces a different > >>>> gcov format when compared to the version of GCC that was used to > >>>> compile the kernel. > >>> > >>> If I understand it correctly, this would mean that you will be able to > >>> use only > >>> one implementation of gcov format at the time. Meaning you will be able > >>> to get > >>> coverage data for module, but not for kernel if it was compiled with > >>> different > >>> gcc(gcda format). This is probably ok if you work only on your module, > >>> but I'm > >>> not sure this is generally the right approach. In this case I would > >>> probably > >>> rather see some support for more gcov formats at the same time(e.g. set of > >>> callback operations per gcov version). Again I'm probably missing > >>> something, but > >>> I still cannot see reason why to add such feature. If you want gcov > >>> support just > >>> compile your kernel and modules with the same gcc version(gcda format). > >>> But if > >>> this is really needed maybe it would be better to consider some parallel > >>> support > >>> for more gcov formats based on the gcov_info version. > >> > >> The callback approach has other drawbacks (see previous mail). > > > > Agreed, I did not realized these problems for the first time when I was > > thinking > > about the callback approach. > > > >> > >>> Would it be possible to add support for the modified gcc 4.7 gcov format > >>> and > >>> deal with this later? I can incorporate your changes: iter to use buffer, > >>> .init_array for modules and possibility to explicitly select the gcda > >>> format. > >>> In this case we will have at least the basic support in kernel. This is > >>> just me > >>> thinking out loud. > >> > >> I think that's an approach I can live with. Maybe the need for a > >> multi-version > >> support will surface again later in a more refined form, but until then > >> there > >> should be no reason to delay base GCC 4.7 support any further. > > > > Great. I can incorporate the changes you proposed and post V2. Or do you > > prefer > > to post it by your self? Based on the info and patches you already provided > > I > > guess you already have something ready. Simply what suits you best :). > > If it's not too much hassle, I'd prefer that you post V2 of your patches. Also > I guess it would make sense to put Andrew Morton on CC since the initial > gcov-patches were picked up by him.
Ok, no problem. I will prepare v2. Again many thanks Peter for your help and input. It's really appreciated. > > -- > Peter Oberparleiter > Linux on System z Development - IBM Germany > -- Frantisek Hrbata -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
