From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Tejun Heo <tj@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
Teck Choon Giam <giamteckchoon@gmail.com>
Subject: Re: Section conflicts with percpu variables
Date: Fri, 29 Oct 2010 07:16:02 -0700 [thread overview]
Message-ID: <4CCAD722.3040004@goop.org> (raw)
In-Reply-To: <4CC9409D.7050405@kernel.org>
On 10/28/2010 02:21 AM, Tejun Heo wrote:
> On 10/27/2010 09:05 PM, Jeremy Fitzhardinge wrote:
>> Hi Tejun,
>>
>> I wonder if you could have a look at this. I have someone reporting
>> compilation failures when using the stock Centos 5 compiler:
>>
>> arch/x86/xen/mmu.c:163: error: __pcpu_scope_xen_cr3 causes a section type conflict
>> arch/x86/xen/mmu.c:164: error: __pcpu_scope_xen_current_cr3 causes a section type conflict
>> arch/x86/xen/mmu.c:163: error: __pcpu_unique_xen_cr3 causes a section type conflict
>> arch/x86/xen/mmu.c:164: error: __pcpu_unique_xen_current_cr3 causes a section type conflict
>>
>> Looking at mmu.i, I can't see why it is picking on these particular
>> per-cpu variables. Do you have any insight into this.
> Hmmm... me neither. section type conflict? Does it make any
> different if you move the definitions near the top of the file or use
> a different compiler version?
This is the first report of this kind I've seen, so it mostly works.
The compiler in question is the stock Centos 5 (.1?) compiler, so it
would be nice to make sure it works as-is.
I've seen section type conflicts with .discard before when discarding a
function and a data type with the same section, which is why I added
general support for .discard.* so they can all get their own sections.
But that doesn't seem to be the case here.
J
WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Tejun Heo <tj@kernel.org>
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
Teck Choon Giam <giamteckchoon@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Section conflicts with percpu variables
Date: Fri, 29 Oct 2010 07:16:02 -0700 [thread overview]
Message-ID: <4CCAD722.3040004@goop.org> (raw)
In-Reply-To: <4CC9409D.7050405@kernel.org>
On 10/28/2010 02:21 AM, Tejun Heo wrote:
> On 10/27/2010 09:05 PM, Jeremy Fitzhardinge wrote:
>> Hi Tejun,
>>
>> I wonder if you could have a look at this. I have someone reporting
>> compilation failures when using the stock Centos 5 compiler:
>>
>> arch/x86/xen/mmu.c:163: error: __pcpu_scope_xen_cr3 causes a section type conflict
>> arch/x86/xen/mmu.c:164: error: __pcpu_scope_xen_current_cr3 causes a section type conflict
>> arch/x86/xen/mmu.c:163: error: __pcpu_unique_xen_cr3 causes a section type conflict
>> arch/x86/xen/mmu.c:164: error: __pcpu_unique_xen_current_cr3 causes a section type conflict
>>
>> Looking at mmu.i, I can't see why it is picking on these particular
>> per-cpu variables. Do you have any insight into this.
> Hmmm... me neither. section type conflict? Does it make any
> different if you move the definitions near the top of the file or use
> a different compiler version?
This is the first report of this kind I've seen, so it mostly works.
The compiler in question is the stock Centos 5 (.1?) compiler, so it
would be nice to make sure it works as-is.
I've seen section type conflicts with .discard before when discarding a
function and a data type with the same section, which is why I added
general support for .discard.* so they can all get their own sections.
But that doesn't seem to be the case here.
J
next prev parent reply other threads:[~2010-10-29 14:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4CC8780C.8090401@goop.org>
2010-10-28 9:21 ` Section conflicts with percpu variables Tejun Heo
2010-10-29 14:16 ` Jeremy Fitzhardinge [this message]
2010-10-29 14:16 ` Jeremy Fitzhardinge
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=4CCAD722.3040004@goop.org \
--to=jeremy@goop.org \
--cc=Xen-devel@lists.xensource.com \
--cc=giamteckchoon@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@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.