> On Mon, May 16, 2011 at 3:38 PM, Andi Kleen <a...@firstfloor.org> wrote: > > Jan Hubicka <hubi...@ucw.cz> writes: > >> Yep, > >> I think it does make sense to share the implementation, but we need to find > >> resonable way to do so. > > > > I doubt this will be very popular with the kernel community, which > > prefers self contained code. > > Won't be surprised if there are objections .. > > > > > Also the interface doesn't change that often or does it? > > As FDO gains popularity, the profile coverage code will change faster > than people may think. To quote some potential ones -- lightweight > ipo, path profiling, call trace profiling etc. > > > > > The current kernel code is for gcc 3. That could be simply > > replaced with a modern gcc 4 interface. > > Rong's approach will let kernel get coverage + FDO support almost for > free -- there is no need for kernel to maintain something is basically > not maintainable.
One other plus for "embeddable gcov" is that Linux kernel is not the only potential consumer of this infrastructure. So from sole gcov maintainer POV, I think adding such support for interface an dmaking libgcov building in its own directory is a positive thing. I doubt I will however have time to implement it myself this stage1 - the list of high priority things is just too long. Patches would be welcome, however. If kernel developers decides to maintain its own variant of libgcov, it is not big problem with me either and I am trying to keep the interface stable unless there are good reasons to break it. It is however clear that we will break libgcov interface this GCC release (we already did) and given new interest in it, probably in releases to come, too. Honza
