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 -- 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
