[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 11 Nov 2008 08:51:11 +0100
From: Takashi Iwai <tiwai@...e.de>
To: Sam Ravnborg <sam@...nborg.org>
Cc: Jeremy Fitzhardinge <jeremy@...p.org>,
Tony Luck <tony.luck@...el.com>,
Isaku Yamahata <yamahata@...inux.co.jp>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Fix section type conflict in arch/ia64/xen/xen_pv_ops.c
At Thu, 6 Nov 2008 22:48:48 +0100,
Sam Ravnborg wrote:
>
> On Thu, Nov 06, 2008 at 10:57:21AM -0800, Jeremy Fitzhardinge wrote:
> > Takashi Iwai wrote:
> > >__initdata and const cannot be always a happy pair, as gcc-4.3.3 gives
> > >the compile errors like:
> > >
> > > arch/ia64/xen/xen_pv_ops.c:156: error: xen_init_ops causes a section
> > > type conflict
> > > arch/ia64/xen/xen_pv_ops.c:340: error: xen_iosapic_ops causes a section
> > > type conflict
> > >
> > >This patch simply removes const from data with __initdata.
> > >
> >
> > Yeah, I've seen these sort of messages before, but I don't see why
> > there's an inherent problem with having const __initdata.
> >
> > Sam?
>
> The root problem here is that in some cases gcc will stuff this into
> a section marked CONST and in other cases not.
> So when we manually specify the section we better not mix const and
> non-const stuff in the same section.
> The problem is that it is very gcc dependent. I have with powerpc
> seen that the same code was not put in CONST with a 32 bit build,
> but with the 64 bit build it was.
> The only cure was to remove the const and use initdata.
> You can try to play with initconst - and it may work.
> But you need to have pretty good build coverage to be sure.
OK, then my original patch should do right :)
Do you guys see any problems with it?
Right now 2.6.28-rc kernel doesn't build, thus this is basically a
regression.
thanks,
Takashi
--
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