[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4AE9B812.2080307@kernel.org>
Date: Thu, 29 Oct 2009 16:43:14 +0100
From: Tejun Heo <tj@...nel.org>
To: "Luck, Tony" <tony.luck@...el.com>
CC: Randy Dunlap <randy.dunlap@...cle.com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
"linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>,
"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
akpm <akpm@...ux-foundation.org>,
Sam Ravnborg <sam@...nborg.org>,
Andreas Gruenbacher <agruen@...e.de>,
Jan Beulich <JBeulich@...ell.com>
Subject: Re: [PATCH -next] ia64/sn: fix percpu warnings
Yiee... lexer/parser problem in genksyms. cc'ing Andreas, Sam and Jan
for help and quoting whole body.
Hello,
Tejun Heo wrote:
> Hello,
>
> Luck, Tony wrote:
>> Ok. x86 doesn't see this because the defconfig has
>> CONFIG_MODVERSIONS is not set
>>
>> If I turn MODVERSION off, then the problem disappears for me.
>>
>> If I turn MODVERSIONS on for x86 (and fudge a driver to make use of
>> softirq_work_list), then x86 gets the CRC warning too.
>
> Right, I can reproduce it here too.
>
>> So this isn't a tool chain problem. Neither x86 nor ia64
>> can handle exported per-cpu array objects when CONFIG_MODVERSIONS
>> is set.
>>
>> Looking at the __crc symbols in the vmlinux for x86 with
>> CONFIG_MODVERSIONS=y I see:
>>
>> 000000006dcaeb88 A __crc_per_cpu__kernel_stack
>> 00000000b3994c7a A __crc_per_cpu__kstat
>> 00000000d917c158 A __crc_per_cpu__node_number
>> w __crc_per_cpu__softirq_work_list
>> 0000000036a1f502 A __crc_per_cpu__softnet_data
>> 0000000057adf756 A __crc_per_cpu__this_cpu_off
>>
>> which explains why "modpost" is unable to find a CRC.
>>
>> Maybe the comments in <linux/module.h> are supposed to be a
>> clue? :
>>
>> #ifdef CONFIG_MODVERSIONS
>> /* Mark the CRC weak since genksyms apparently decides not to
>> * generate a checksums for some symbols */
>> #define __CRC_SYMBOL(sym, sec) \
>> extern void *__crc_##sym __attribute__((weak)); \
>> static const unsigned long __kcrctab_##sym \
>> __used \
>> __attribute__((section("__kcrctab" sec), unused)) \
>> = (unsigned long) &__crc_##sym;
>>
>> But not enough of a clue for me :-(
>
> I have no idea either. I'll dig a bit and try to find out what's
> going on.
So, the problem is that genksyms can't understand the following.
__typeof__(int [10]) my_ar;
EXPORT_SYMBOL(my_ar);
Would it be difficult to teach it how to parse it?
Thanks.
--
tejun
--
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/
Powered by blists - more mailing lists