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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 29 Jul 2010 18:25:35 +0200
From:	Karol Lewandowski <k.lewandowsk@...sung.com>
To:	Peter Oberparleiter <oberpar@...ux.vnet.ibm.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	gdavis@...sta.com
Subject: Re: GCOV doesn't seem to work on ARM with kernel 2.6.35-rc6

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/