Hello,
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've enabled following in my .config:
CONFIG_GCOV_KERNEL=y
CONFIG_DEBUG_FS=y
After successful boot I see no gcov-related files other than
/sys/kernel/debug/gcov/reset.
From my knowledge (and from my previous experience with out-of-tree
gcov patchset) whole directory structure shall be created along with
.gcda files and various symlinks.
I haven't used mainline gcov support yet, so maybe there are additional
steps needed to get it going? Lecture of Documentation/gcov.txt didn't
help much.
Hints?
Thanks in advance.
On 07/26/2010 12:32 PM, Karol Lewandowski wrote:
> Hello,
>
> 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've enabled following in my .config:
>
> CONFIG_GCOV_KERNEL=y
> CONFIG_DEBUG_FS=y
>
> After successful boot I see no gcov-related files other than
> /sys/kernel/debug/gcov/reset.
>
> From my knowledge (and from my previous experience with out-of-tree
> gcov patchset) whole directory structure shall be created along with
> .gcda files and various symlinks.
I forgot to add that I've added "GCOV_PROFILE := y" to at least
fs/Makefile
kernel/Makefile
and few others. Thus, I expect to find something more than just
./reset file.
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've enabled following in my .config:
>>
>> CONFIG_GCOV_KERNEL=y
>> CONFIG_DEBUG_FS=y
>>
>> After successful boot I see no gcov-related files other than
>> /sys/kernel/debug/gcov/reset.
>>
>> From my knowledge (and from my previous experience with out-of-tree
>> gcov patchset) whole directory structure shall be created along with
>> .gcda files and various symlinks.
This expectation is correct.
> I forgot to add that I've added "GCOV_PROFILE := y" to at least
>
> fs/Makefile
> kernel/Makefile
>
> and few others. Thus, I expect to find something more than just
> ./reset file.
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
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:
---
include/asm-generic/vmlinux.lds.h | 1 +
kernel/module.c | 6 ++++++
2 files changed, 7 insertions(+)
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -443,6 +443,7 @@
#define KERNEL_CTORS() . = ALIGN(8); \
VMLINUX_SYMBOL(__ctors_start) = .; \
*(.ctors) \
+ *(.init_array) \
VMLINUX_SYMBOL(__ctors_end) = .;
#else
#define KERNEL_CTORS()
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2405,6 +2405,12 @@ static noinline struct module *load_modu
#ifdef CONFIG_CONSTRUCTORS
mod->ctors = section_objs(hdr, sechdrs, secstrings, ".ctors",
sizeof(*mod->ctors), &mod->num_ctors);
+ if (!mod->num_ctors) {
+ /* Could be an EABI compiler. */
+ mod->ctors = section_objs(hdr, sechdrs, secstrings,
+ ".init_array", sizeof(*mod->ctors),
+ &mod->num_ctors);
+ }
#endif
#ifdef CONFIG_TRACEPOINTS
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.
Thank you very much for your help!
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??
Regards,
Peter Oberparleiter
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) \
--- a/kernel/gcov/Kconfig
+++ b/kernel/gcov/Kconfig
+config GCOV_CTORS
+ string
+ depends on GCOV_KERNEL
+ default ".init_array" if ARM && AEABI
+ default ".ctors"
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2296,7 +2296,7 @@ static noinline struct module *load_module(void
__user *umod,
"__kcrctab_unused_gpl");
#endif
#ifdef CONFIG_CONSTRUCTORS
- mod->ctors = section_objs(hdr, sechdrs, secstrings, ".ctors",
+ mod->ctors = section_objs(hdr, sechdrs, secstrings,
CONFIG_GCOV_CTORS, sizeof(*mod->ctors), &mod->num_ctors);
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.
> --- 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.
>
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -2296,7 +2296,7 @@ static noinline struct module *load_module(void
> __user *umod,
> "__kcrctab_unused_gpl");
> #endif
> #ifdef CONFIG_CONSTRUCTORS
> - mod->ctors = section_objs(hdr, sechdrs, secstrings, ".ctors",
> + mod->ctors = section_objs(hdr, sechdrs, secstrings, CONFIG_GCOV_CTORS,
> sizeof(*mod->ctors), &mod->num_ctors);
Regards,
Peter Oberparleiter
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.
>
>> --- 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).
Thanks.
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.
On 03.08.2010 07:20, George G. Davis wrote:
> 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. ; )
I wasn't aware of the patch until now or I would have replied.
> 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.
Ok, that makes things easier. Your patch looks good to me, but it needs
to be split into two parts:
1. kernel: constructor support for ARM EABI compilers
2. gcov: enable GCOV_PROFILE_ALL for arm
For both, it would be great if you could provide a good explanation of
what the changes do and why they are needed for arm. For 1, it's
obvious, but the author of the original arm-hack patches wasn't too
clear about those points for 2.
Also, when you re-post these patches, please add the following people to
cc (in addition to the current cc list):
1. For the constructor change:
Rusty Russell <[email protected]> (for module comments)
Sam Ravnborg <[email protected]> (for kbuild comnents)
Michal Marek <[email protected]> (for kbuild comments)
Andrew Morton <[email protected]> (hopefully for integration)
2. For the gcov-arm change:
Andrew Morton <[email protected]>
Regards,
Peter