From: Vineet Gupta <vgupta@synopsys.com>
To: "acme@redhat.com" <acme@redhat.com>, Noam Camus <noamc@ezchip.com>
Cc: "peterz@infradead.org" <peterz@infradead.org>,
Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-perf-users@vger.kernel.org"
<linux-perf-users@vger.kernel.org>,
"andi@firstfloor.org" <andi@firstfloor.org>,
"dsahern@gmail.com" <dsahern@gmail.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>,
"dvhart@linux.intel.com" <dvhart@linux.intel.com>,
Gilad Ben Yossef <giladb@ezchip.com>
Subject: Re: [RFC] perf: fix building for ARCv1
Date: Wed, 10 Feb 2016 08:39:43 +0530 [thread overview]
Message-ID: <56BAA9F7.50807@synopsys.com> (raw)
In-Reply-To: <20160205161027.GG28242@kernel.org>
On Friday 05 February 2016 09:40 PM, acme@redhat.com wrote:
> Em Fri, Feb 05, 2016 at 11:18:52AM +0000, Noam Camus escreveu:
>> Well here for EZchip I also see the:
>> undefined reference to `__sync_add_and_fetch_4'
>> undefined reference to `__sync_sub_and_fetch_4'
>
> Yeah, because there is no: tools/arch/arc/include/asm/atomic.h, can't
> you guys adapt arch/arc/include/asm/atomic.h to use in userspace?
Sure - however we need to support 3 variants: LLSC, !LLSC, EZCHIP
If needed, latter 2 could be done using a new atomic assist syscall
I presume kernel Kconfig items are no go in this header so this diversity
management needs to use toolchain defined macros e.g. __ezchip__
>
> - Arnaldo
>
>> This is since at file tools/include/asm/atomic.h we use the generic implementation
>> If for ARC I could use just like x86 my own header file then functions like:
>> atomic_inc()
>> atomic_dec_and_test()
>> Are easy to implement and you may see an example for such atomic methods in my patch set for the new platform.
>>
>> You however wants to use some GCC flag -matomic which I assume somehow will implement the above __sync*.
>> I can't find the implementation but if it uses LLSC then it won't work for me since I am not supporting LLSC.
>
>> So seem that either I have my own header at kernel or that I need to
>> change the GCC implementation for __sync* to use my atomic
>> instructions. I am personally tend to the x86 solution and not the
>> generic one since changing GCC will require to have new compiler
>> dependency.
WARNING: multiple messages have this Message-ID (diff)
From: vgupta@synopsys.com (Vineet Gupta)
To: linux-snps-arc@lists.infradead.org
Subject: [RFC] perf: fix building for ARCv1
Date: Wed, 10 Feb 2016 08:39:43 +0530 [thread overview]
Message-ID: <56BAA9F7.50807@synopsys.com> (raw)
In-Reply-To: <20160205161027.GG28242@kernel.org>
On Friday 05 February 2016 09:40 PM, acme@redhat.com wrote:
> Em Fri, Feb 05, 2016 at 11:18:52AM +0000, Noam Camus escreveu:
>> Well here for EZchip I also see the:
>> undefined reference to `__sync_add_and_fetch_4'
>> undefined reference to `__sync_sub_and_fetch_4'
>
> Yeah, because there is no: tools/arch/arc/include/asm/atomic.h, can't
> you guys adapt arch/arc/include/asm/atomic.h to use in userspace?
Sure - however we need to support 3 variants: LLSC, !LLSC, EZCHIP
If needed, latter 2 could be done using a new atomic assist syscall
I presume kernel Kconfig items are no go in this header so this diversity
management needs to use toolchain defined macros e.g. __ezchip__
>
> - Arnaldo
>
>> This is since at file tools/include/asm/atomic.h we use the generic implementation
>> If for ARC I could use just like x86 my own header file then functions like:
>> atomic_inc()
>> atomic_dec_and_test()
>> Are easy to implement and you may see an example for such atomic methods in my patch set for the new platform.
>>
>> You however wants to use some GCC flag -matomic which I assume somehow will implement the above __sync*.
>> I can't find the implementation but if it uses LLSC then it won't work for me since I am not supporting LLSC.
>
>> So seem that either I have my own header at kernel or that I need to
>> change the GCC implementation for __sync* to use my atomic
>> instructions. I am personally tend to the x86 solution and not the
>> generic one since changing GCC will require to have new compiler
>> dependency.
next prev parent reply other threads:[~2016-02-10 3:09 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1445088959-3058-1-git-send-email-abrodkin@synopsys.com>
2015-10-17 14:19 ` [RFC] perf: fix building for ARCv1 Vineet Gupta
2015-10-18 11:15 ` Alexey Brodkin
2015-10-18 11:15 ` Alexey Brodkin
2015-10-18 23:14 ` Andi Kleen
2015-10-18 23:14 ` Andi Kleen
2015-10-19 4:58 ` Vineet Gupta
2015-10-19 5:49 ` Andi Kleen
2015-10-19 5:49 ` Andi Kleen
2015-10-19 9:28 ` Vineet Gupta
2015-10-19 9:35 ` Peter Zijlstra
2015-10-19 9:46 ` Vineet Gupta
2015-10-19 9:51 ` Peter Zijlstra
2015-10-19 10:04 ` Vineet Gupta
2015-10-20 8:00 ` Vineet Gupta
2015-10-20 10:11 ` Peter Zijlstra
2015-10-20 10:45 ` Vineet Gupta
2015-10-29 15:58 ` Alexey Brodkin
2015-10-29 15:58 ` Alexey Brodkin
2015-10-29 15:58 ` Alexey Brodkin
2015-10-30 6:19 ` Vineet Gupta
2015-10-30 6:19 ` Vineet Gupta
2016-02-03 16:20 ` Alexey Brodkin
2016-02-03 16:20 ` Alexey Brodkin
[not found] ` <1454516455.2811.4.camel__10775.5710989752$1454516490$gmane$org@synopsys.com>
2016-02-04 4:13 ` Vineet Gupta
2016-02-04 4:13 ` Vineet Gupta
2016-02-04 4:13 ` Vineet Gupta
2016-02-05 11:18 ` Noam Camus
2016-02-05 11:18 ` Noam Camus
2016-02-05 16:10 ` acme
2016-02-05 16:10 ` acme
2016-02-10 3:09 ` Vineet Gupta [this message]
2016-02-10 3:09 ` Vineet Gupta
2016-10-18 18:58 ` Vineet Gupta
2016-10-18 18:58 ` Vineet Gupta
2016-10-24 16:17 ` [PATCH-v2] ARC: syscall for userspace cmpxchg assist Vineet Gupta
2016-10-24 16:17 ` Vineet Gupta
2016-11-04 20:16 ` Vineet Gupta
2016-11-04 20:16 ` Vineet Gupta
2016-11-07 18:50 ` [PATCH] ARC: tweak semantics of " Vineet Gupta
2016-11-07 18:50 ` Vineet Gupta
2015-10-30 6:21 ` [RFC] perf: fix building for ARCv1 Vineet Gupta
2015-10-30 6:21 ` Vineet Gupta
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=56BAA9F7.50807@synopsys.com \
--to=vgupta@synopsys.com \
--cc=Alexey.Brodkin@synopsys.com \
--cc=acme@redhat.com \
--cc=andi@firstfloor.org \
--cc=dsahern@gmail.com \
--cc=dvhart@linux.intel.com \
--cc=giladb@ezchip.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=noamc@ezchip.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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.