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 :). Many thanks Peter > > > -- > Peter Oberparleiter > Linux on System z Development - IBM Germany > -- Frantisek Hrbata -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
