[oe] [meta-oe][PATCH v2] leveldb: fix compile errors for mips with DEFAULTTUNE mips

Kang Kai Kai.Kang at windriver.com
Wed Mar 6 05:44:18 UTC 2019


On 2019/3/6 下午1:31, Khem Raj wrote:
> On Tue, Mar 5, 2019 at 9:16 PM Kang Kai <Kai.Kang at windriver.com> wrote:
>> On 2019/3/6 上午11:49, Khem Raj wrote:
>>>
>>> On 3/5/19 7:39 PM, kai.kang at windriver.com wrote:
>>>> From: Kai Kang <kai.kang at windriver.com>
>>>>
>>>> It fails to compile leveldb for qemumips with DEFAULTTUNE 'mips':
>>>>
>>>> | {standard input}: Assembler messages:
>>>> | {standard input}:8004: Error: opcode not supported on this processor:
>>>>     mips1 (mips1) `sync'
>>>> | {standard input}:10296: Error: opcode not supported on this processor:
>>>>     mips1 (mips1) `sync'
>>>> | make: *** [out-shared/db/db_bench.o] Error 1
>>>>
>>>> Asm instruction 'sync' is called in platform-specific function
>>>> MemoryBarrier() which is used by AtomicPointer(). Comment out the
>>>> definition of MemoryBarrier() for mips to avoid the errors. And turn to
>>>> use AtomicPointer() based on C++11 <atomc>.
>>>>
>>>> Signed-off-by: Kai Kang <kai.kang at windriver.com>
>>>> ---
>>>>    ...fine-function-MemoryBarrier-for-mips.patch | 43 +++++++++++++++++++
>>>>    meta-oe/recipes-dbs/leveldb/leveldb_git.bb    |  1 +
>>>>    2 files changed, 44 insertions(+)
>>>>    create mode 100644
>>>> meta-oe/recipes-dbs/leveldb/leveldb/do-not-define-function-MemoryBarrier-for-mips.patch
>>>>
>>>> diff --git
>>>> a/meta-oe/recipes-dbs/leveldb/leveldb/do-not-define-function-MemoryBarrier-for-mips.patch
>>>> b/meta-oe/recipes-dbs/leveldb/leveldb/do-not-define-function-MemoryBarrier-for-mips.patch
>>>>
>>>> new file mode 100644
>>>> index 000000000..fc7743030
>>>> --- /dev/null
>>>> +++
>>>> b/meta-oe/recipes-dbs/leveldb/leveldb/do-not-define-function-MemoryBarrier-for-mips.patch
>>>> @@ -0,0 +1,43 @@
>>>> +It fails to compile leveldb for qemumips with default tune 'mips':
>>>> +
>>>> +| {standard input}: Assembler messages:
>>>> +| {standard input}:8004: Error: opcode not supported on this processor:
>>>> +  mips1 (mips1) `sync'
>>>> +| {standard input}:10296: Error: opcode not supported on this
>>>> processor:
>>>> +  mips1 (mips1) `sync'
>>>> +| make: *** [out-shared/db/db_bench.o] Error 1
>>>> +
>>>> +Asm instruction 'sync' is called in platform-specific function
>>>> +MemoryBarrier() which is used by AtomicPointer(). Comment out the
>>>> +definition of MemoryBarrier() for mips to avoid the errors. And turn to
>>>> +use AtomicPointer() based on C++11 <atomic>.
>>>> +
>>>> +Upstream-Status: Inappropriate [oe specific]
>>>> +
>>>> +Signed-off-by: Kai Kang <kai.kang at windriver.com>
>>>> +
>>>> +---
>>>> + port/atomic_pointer.h | 10 +++++-----
>>>> + 1 file changed, 5 insertions(+), 5 deletions(-)
>>>> +
>>>> +diff --git a/port/atomic_pointer.h b/port/atomic_pointer.h
>>>> +index 1c4c7aa..7025ac3 100644
>>>> +--- a/port/atomic_pointer.h
>>>> ++++ b/port/atomic_pointer.h
>>>> +@@ -113,11 +113,11 @@ inline void MemoryBarrier() {
>>>> + #define LEVELDB_HAVE_MEMORY_BARRIER
>>>> +
>>>> + // MIPS
>>>> +-#elif defined(ARCH_CPU_MIPS_FAMILY) && defined(__GNUC__)
>>>> +-inline void MemoryBarrier() {
>>>> +-  __asm__ __volatile__("sync" : : : "memory");
>>>> +-}
>>>> +-#define LEVELDB_HAVE_MEMORY_BARRIER
>>>> ++//#elif defined(ARCH_CPU_MIPS_FAMILY) && defined(__GNUC__)
>>>> ++//inline void MemoryBarrier() {
>>>> ++//  __asm__ __volatile__("sync" : : : "memory");
>>>> ++//}
>>>> ++//#define LEVELDB_HAVE_MEMORY_BARRIER
>>>> +
>>> this is punishing all mips o32 variants.
>> How about only apply the patch when DEFAULTTUNE is 'mips', such as
>> something looks like:
>>
>> python ()  {
>>
>>       if d.getVar('DEFAULTTUNE') == 'mips':
>>
>>           d.appendVar('SRC_URI', '
>> file://do-not-define-function-MemoryBarrier-for-mips.patch')
>>
>> }
>
> None of these are as good as first patch. Ideally you should change
> the defaulttune


But defaulttune could be overridden by user configure. Even could 
configure qemumips64 with defaulttune 'mips'.
I'll try to fix it from oe side based on first patch.

Kai


>

-- 
Kai Kang



More information about the Openembedded-devel mailing list