All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
To: "George G. Davis" <gdavis@mvista.com>
Cc: Karol Lewandowski <k.lewandowsk@samsung.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: GCOV doesn't seem to work on ARM with kernel 2.6.35-rc6
Date: Tue, 03 Aug 2010 11:12:15 +0200	[thread overview]
Message-ID: <4C57DD6F.1010004@linux.vnet.ibm.com> (raw)
In-Reply-To: <20100803052051.GA17719@mvista.com>

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 <rusty@rustcorp.com.au> (for module comments)
Sam Ravnborg <sam@ravnborg.org> (for kbuild comnents)
Michal Marek <mmarek@suse.cz> (for kbuild comments)
Andrew Morton <akpm@linux-foundation.org> (hopefully for integration)

2. For the gcov-arm change:
Andrew Morton <akpm@linux-foundation.org>


Regards,
   Peter


      reply	other threads:[~2010-08-03  9:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-26 10:32 GCOV doesn't seem to work on ARM with kernel 2.6.35-rc6 Karol Lewandowski
2010-07-26 10:37 ` Karol Lewandowski
2010-07-26 16:57   ` Peter Oberparleiter
2010-07-27  7:35     ` Karol Lewandowski
2010-07-28 13:12       ` Peter Oberparleiter
2010-07-28 13:44         ` Karol Lewandowski
2010-07-28 15:57           ` Peter Oberparleiter
2010-07-29 16:25             ` Karol Lewandowski
2010-08-03  5:20               ` George G. Davis
2010-08-03  9:12                 ` Peter Oberparleiter [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C57DD6F.1010004@linux.vnet.ibm.com \
    --to=oberpar@linux.vnet.ibm.com \
    --cc=gdavis@mvista.com \
    --cc=k.lewandowsk@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.