From: Helge Deller <deller@gmx.de>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Sam Ravnborg <sam-uyr5N9Q2VtJg9hUCZPvPmw@public.gmane.org>,
Frans Pop <elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>,
linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org,
parisc-linux-T/XaZq8tFt7U4lJK3ijXoz+iFHGzDt/a@public.gmane.org
Subject: Re: nfs: __setup_str_nfs_root_setup causes a section type conflict
Date: Wed, 05 Aug 2009 21:47:58 +0200 [thread overview]
Message-ID: <4A79E1EE.9070107@gmx.de> (raw)
In-Reply-To: <1249337493.18161.52.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
On 08/04/2009 12:11 AM, Trond Myklebust wrote:
> On Mon, 2009-08-03 at 23:52 +0200, Sam Ravnborg wrote:
>> On Mon, Aug 03, 2009 at 05:07:23PM -0400, Trond Myklebust wrote:
>>> On Mon, 2009-08-03 at 22:57 +0200, Frans Pop wrote:
>>>> $ make init/do_mounts.o
>>>> CHK include/linux/version.h
>>>> CHK include/linux/utsrelease.h
>>>> SYMLINK include/asm -> include/asm-parisc
>>>> CALL scripts/checksyscalls.sh
>>>> CC init/do_mounts.o
>>>>
>>>> while:
>>>>
>>>> $ make fs/nfs/nfsroot.o
>>>> CHK include/linux/version.h
>>>> CHK include/linux/utsrelease.h
>>>> SYMLINK include/asm -> include/asm-parisc
>>>> CALL scripts/checksyscalls.sh
>>>> CC fs/nfs/nfsroot.o
>>>> fs/nfs/nfsroot.c:403: error: __setup_str_nfs_root_setup causes a section type
>>>> conflict
>>> To me that looks like some kind of compiler bug.
>> unspecified behaviour is a better name for it.
>>
>> We have two variables we have forced a section on.
>> One variable is marked RO by the compiler while the other is not.
>> This results in a section type conflict because all
>> symbols needs to have the same falgs.
>>
>> We usually triggers this with powerpc builds (64 bit IIRC),
>> and now with parisc too.
>>
>> The only way to fix it is to move one of the offending
>> variables to __initdata.
>> There is two variales to consider - the compiler only
>> mention one of them.
Yes.
It seems this was already once described on the parisc mailing list:
http://article.gmane.org/gmane.linux.ports.parisc/1816
Helge
>>
>> Trying to declare the variables const etc usually has
>> no good effect.
>
> So why would it be happening in the NFSroot case, but not in
> do_mounts.c? They're both using the standard __setup() macro with a
> constant string, and an __init function argument.
>
> Futhermore, when grepping for '__initconst', it seems that the
> combination with 'static const' is the norm rather than the exception.
WARNING: multiple messages have this Message-ID (diff)
From: Helge Deller <deller@gmx.de>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Sam Ravnborg <sam@ravnborg.org>, Frans Pop <elendil@planet.nl>,
linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org,
parisc-linux@lists.parisc-linux.org
Subject: Re: nfs: __setup_str_nfs_root_setup causes a section type conflict
Date: Wed, 05 Aug 2009 21:47:58 +0200 [thread overview]
Message-ID: <4A79E1EE.9070107@gmx.de> (raw)
In-Reply-To: <1249337493.18161.52.camel@heimdal.trondhjem.org>
On 08/04/2009 12:11 AM, Trond Myklebust wrote:
> On Mon, 2009-08-03 at 23:52 +0200, Sam Ravnborg wrote:
>> On Mon, Aug 03, 2009 at 05:07:23PM -0400, Trond Myklebust wrote:
>>> On Mon, 2009-08-03 at 22:57 +0200, Frans Pop wrote:
>>>> $ make init/do_mounts.o
>>>> CHK include/linux/version.h
>>>> CHK include/linux/utsrelease.h
>>>> SYMLINK include/asm -> include/asm-parisc
>>>> CALL scripts/checksyscalls.sh
>>>> CC init/do_mounts.o
>>>>
>>>> while:
>>>>
>>>> $ make fs/nfs/nfsroot.o
>>>> CHK include/linux/version.h
>>>> CHK include/linux/utsrelease.h
>>>> SYMLINK include/asm -> include/asm-parisc
>>>> CALL scripts/checksyscalls.sh
>>>> CC fs/nfs/nfsroot.o
>>>> fs/nfs/nfsroot.c:403: error: __setup_str_nfs_root_setup causes a section type
>>>> conflict
>>> To me that looks like some kind of compiler bug.
>> unspecified behaviour is a better name for it.
>>
>> We have two variables we have forced a section on.
>> One variable is marked RO by the compiler while the other is not.
>> This results in a section type conflict because all
>> symbols needs to have the same falgs.
>>
>> We usually triggers this with powerpc builds (64 bit IIRC),
>> and now with parisc too.
>>
>> The only way to fix it is to move one of the offending
>> variables to __initdata.
>> There is two variales to consider - the compiler only
>> mention one of them.
Yes.
It seems this was already once described on the parisc mailing list:
http://article.gmane.org/gmane.linux.ports.parisc/1816
Helge
>>
>> Trying to declare the variables const etc usually has
>> no good effect.
>
> So why would it be happening in the NFSroot case, but not in
> do_mounts.c? They're both using the standard __setup() macro with a
> constant string, and an __init function argument.
>
> Futhermore, when grepping for '__initconst', it seems that the
> combination with 'static const' is the norm rather than the exception.
next prev parent reply other threads:[~2009-08-05 19:48 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-31 12:46 nfs: __setup_str_nfs_root_setup causes a section type conflict Frans Pop
[not found] ` <200907311446.33486.elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
2009-08-01 22:10 ` Frans Pop
2009-08-01 22:10 ` Frans Pop
[not found] ` <200908020010.30459.elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
2009-08-03 18:23 ` Trond Myklebust
2009-08-03 18:23 ` Trond Myklebust
[not found] ` <1249323782.18161.2.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-03 19:21 ` Frans Pop
2009-08-03 19:21 ` Frans Pop
2009-08-03 19:47 ` Trond Myklebust
2009-08-03 20:57 ` Frans Pop
[not found] ` <200908032257.51739.elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org>
2009-08-03 21:07 ` Trond Myklebust
2009-08-03 21:07 ` Trond Myklebust
[not found] ` <1249333643.18161.36.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-03 21:34 ` Frans Pop
2009-08-03 21:34 ` Frans Pop
2009-08-03 21:52 ` Sam Ravnborg
2009-08-03 21:52 ` Sam Ravnborg
[not found] ` <20090803215237.GA956-OoSGOWW0KRunlFQ6Q1D1Y0B+6BGkLq7r@public.gmane.org>
2009-08-03 22:11 ` Trond Myklebust
2009-08-03 22:11 ` Trond Myklebust
[not found] ` <1249337493.18161.52.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-08-05 19:47 ` Helge Deller [this message]
2009-08-05 19:47 ` Helge Deller
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=4A79E1EE.9070107@gmx.de \
--to=deller@gmx.de \
--cc=elendil-EIBgga6/0yRmR6Xm/wNWPw@public.gmane.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=parisc-linux-T/XaZq8tFt7U4lJK3ijXoz+iFHGzDt/a@public.gmane.org \
--cc=sam-uyr5N9Q2VtJg9hUCZPvPmw@public.gmane.org \
--cc=trond.myklebust@fys.uio.no \
/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.