Re: GCOV doesn't seem to work on ARM with kernel 2.6.35-rc6

[George G. Davis]

 Hi,

On Thu, Jul 29, 2010 at 06:25:35PM +0200, Karol Lewandowski wrote:
> On 07/28/2010 05:57 PM, Peter Oberparleiter wrote:
> >On 28.07.2010 15:44, Karol Lewandowski wrote:
> >>On 07/28/2010 03:12 PM, Peter Oberparleiter wrote:
> >>>On 27.07.2010 09:35, Karol Lewandowski wrote:
> >>>>On 07/26/2010 06:57 PM, Peter Oberparleiter wrote:
> >>>>>Karol Lewandowski wrote:
> >>>>>>On 07/26/2010 12:32 PM, Karol Lewandowski wrote:
> >>>>>>>I'm trying to use code coverage measurements with mainline Linux
> >>>>>>>kernel
> >>>>>>>2.6.35-rc6 on ARM platform (specifically on Samsung's S5PC110
> >>>>>>>board).
> >>>>...
> >>>>>I just tested gcov support for 2.6.35-rc6 on s390 and it works without
> >>>>>a problem. My assumption would be that you are using an EABI-GCC to
> >>>>>compile your kernel. Those compilers name their constructor symbols
> >>>>
> >>>>Exactly.
> >>>>
> >>>>>differently than the vanilla GCC so that the whole constructor calling
> >>>>>mechanism on which the gcov support relies, will fail. If that is
> >>>>>indeed the case, the following testing patch should solve your
> >>>>>problem:
> >>>>
> >>>>Yes, that was the case and your patch indeed solved my problem.
> >>>
> >>>Excellent. I could imagine that other ARM users might also benefit from
> >>>this patch. Before I submit it for integration though, I need to make
> >>>sure that it also works for kernel modules. Could you enable profiling
> >>>for a kernel module and verify that you are seeing files in
> >>>/sys/kernel/debug/gcov belonging to that module??
> >>
> >>That does work too.
> >>
> >>However, having seen this[x] patch I would ask if constructor name might
> >>be dynamically selected via user-(in)visible Kconfig option (like in
> >>that patch?) I've tested it and it does seem to work too.
> >>
> >>[x]
> >>http://groups.google.com/group/linux.kernel/browse_thread/thread/84439151c5386e0f/d7dbec62b9d7989f?show_docid=d7dbec62b9d7989f
> >>
> >>
> >>
> >>I've copy pasted interesting parts from that patch below - I'm sure you
> >>get the idea.
> >>
> >>Thanks.
> >>
> >>--- a/include/asm-generic/vmlinux.lds.h
> >>+++ b/include/asm-generic/vmlinux.lds.h
> >>@@ -442,7 +442,7 @@
> >>#ifdef CONFIG_CONSTRUCTORS
> >>#define KERNEL_CTORS() . = ALIGN(8); \
> >>VMLINUX_SYMBOL(__ctors_start) = .; \
> >>- *(.ctors) \
> >>+ *(CONFIG_GCOV_CTORS) \
> >
> >This should be named differently - gcov uses constructors but this
> >doesn't mean that constructors rely on gcov at all.

I actually changed that patch [x] long ago relative to the above but
haven't gotten around to following up with a new version and no one
has been anxious to reply about it since anyway.  ; )  The original
version of [x] had a GCOV_CTORS depends on GCOV_KERNEL bug where
GCOV_KERNEL could be disabled resulting in a CONSTRUCTORS build
error due to undefined GCOV_CTORS.  A new version of [x] is
attached below.

> >
> >>--- a/kernel/gcov/Kconfig
> >>+++ b/kernel/gcov/Kconfig
> >>+config GCOV_CTORS
> >>+ string
> >>+ depends on GCOV_KERNEL
> >>+ default ".init_array" if ARM && AEABI
> >>+ default ".ctors"
> >
> >Is it guaranteed that gcc will only create EABI compliant object files
> >if CONFIG_AEABI is defined? I don't have personal experience with arm so
> >my previous assumption was that if you're using an EABI gcc, you would
> >always get EABI object code, no matter what the compiler options were.
> 
> Honestly - I don't know.  Maybe George - author of cited patch could
> explain this?  (CC added).

Yes that is correct.

Thanks!

--
Regards,
George

> 
> Thanks.