[llvmlinux] "make test" for x86_64 target just hung there, why?
sedat.dilek at gmail.com
Sat Sep 12 10:25:40 UTC 2015
On Sat, Sep 12, 2015 at 11:30 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote:
> On Sat, Sep 12, 2015 at 5:36 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote:
>> On Fri, Sep 11, 2015 at 8:37 PM, Daniel Sanders
>> <Daniel.Sanders at imgtec.com> wrote:
>>> It could be that GCC does more inlining and optimises the bug away. This happened to me with the slab allocator initialization on the Mips arch.
>>> At the time, I was able to reproduce it in GCC by making the inline and always_inline macros empty. I don't recall the exact spelling of those macros, they may have additional underscores.
>> Hi Daniel,
>> nice work on MIPS and the LLVM/Clang's integrated assembler works on MIPS :-).
>> YUPP, the inline (always_inline) area is where I also think is the problem.
>> I fell over your patch  as I "backported" it for Linux v4.1.
>> Do you remember how you made that "inline" macros "empty"?
>> You point exactly where I want to play with...
>> There is a include/linux/compiler-gcc.h file where inlining is defined
>> (see below) plus LLVMLinux has an own include/linux/compiler-clang.h
>> [ include/linux/compiler-gcc.h ]
>> * Force always-inline if the user requests it so via the .config,
>> * or if gcc is too old:
>> #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) || \
>> !defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4)
>> #define inline inline __attribute__((always_inline))
>> notrace __maybe_unused
>> #define __inline__ __inline__ __attribute__((always_inline))
>> notrace __maybe_unused
>> #define __inline __inline __attribute__((always_inline)) notrace
>> /* A lot of inline functions can cause havoc with function tracing */
>> #define inline inline notrace __maybe_unused
>> #define __inline__ __inline__ notrace __maybe_unused
>> #define __inline __inline notrace __maybe_unused
>> #define __always_inline inline __attribute__((always_inline))
>> #define noinline __attribute__((noinline))
>> I saw that for x86_64 arch setting CONFIG_OPTIMIZE_INLINING had no
>> effect with clang v3.7 (lib/bitmap always BROKEN).
>> x86_64 linux-arch has always CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y.
>> So, how can I force one of the three inline "types" or make them "empty"?
>> Where is the right place - in compiler-gcc.h or in compiler-clang.h file?
>> Just for testing!
>> Talking on #llvm (OFTC) with two guys (echristo and majnemer)...
>> Both confirmed the defined behaviour in compiler-gcc.h seems to be
>> correct, but they needed more context as they have no clue about the
>> Linux-kernel :-).
>> From this discussion... LLVM/Clang's default behaviour is to do an
>> I asked for a compiler-flag to change or disable that behaviour, but
>> that seems not to exist.
>> Before writing a LLVM/Clang bug-report I wanted to see if it is doable
>> on the kernel-side.
>> As said building a llvmlinux-patched Linux v4.2 with gcc v4.9 boots on
>> my machine!
>> As a conclusion, it looks like a LLVM/Clang (inline optimization) bug to me.
>> Please, give me some clear instructions on setting inline macros or
>> how to make them "empty".
> When doing a change like this...
> [ include/linux/bitmap.h ]
> -extern int __bitmap_weight(const unsigned long *bitmap, unsigned int nbits);
> +extern noinline int __bitmap_weight(const unsigned long *bitmap,
> unsigned int nbits);
> ...I get the same objdump like with gcc v4.9...
> $ objdump -drw lib/bitmap.o | grep bitmap_weight
> 0000000000000670 <__bitmap_weight>:
> 681: 74 26 je 6a9 <__bitmap_weight+0x39>
> 693: e8 00 00 00 00 callq 698
> <__bitmap_weight+0x28> 694: R_X86_64_PC32
> 6a4: 75 ea jne 690 <__bitmap_weight+0x20>
> 6ad: 74 1c je 6cb <__bitmap_weight+0x5b>
> 6c2: e8 00 00 00 00 callq 6c7
> <__bitmap_weight+0x57> 6c3: R_X86_64_PC32
> f11: e8 00 00 00 00 callq f16 <bitmap_remap+0x56>
> f12: R_X86_64_PC32 __bitmap_weight-0x4
> f5b: e8 00 00 00 00 callq f60 <bitmap_remap+0xa0>
> f5c: R_X86_64_PC32 __bitmap_weight-0x4
> 104f: e8 00 00 00 00 callq 1054
> <bitmap_bitremap+0x24> 1050: R_X86_64_PC32
> 106e: e8 00 00 00 00 callq 1073
> <bitmap_bitremap+0x43> 106f: R_X86_64_PC32
The objdump looked good :-).
The generated Linux-kernel does not boot on bare metal and shows the
same call-trace in QEMU.
- Sedat -
> - Sedat -
>> - Sedat -
>>  http://git.linuxfoundation.org/?p=llvmlinux.git;a=blob_plain;f=arch/all/patches/ARCHIVE/correct-size_index-table-before-replacing-the-bootst.patch;hb=HEAD
>>  http://git.linuxfoundation.org/?p=llvmlinux.git;a=blob;f=arch/all/patches/compiler-gcc.patch
>>> Hope that helps.
>>> From: llvmlinux-bounces at lists.linuxfoundation.org [llvmlinux-bounces at lists.linuxfoundation.org] on behalf of Sedat Dilek [sedat.dilek at gmail.com]
>>> Sent: 11 September 2015 17:10
>>> To: pageexec at gmail.com
>>> Cc: llvmlinux at lists.linuxfoundation.org; David Woodhouse
>>> Subject: Re: [llvmlinux] "make test" for x86_64 target just hung there, why?
>>> On Wed, Sep 9, 2015 at 10:24 PM, PaX Team <pageexec at gmail.com> wrote:
>>>> On 9 Sep 2015 at 12:12, Sedat Dilek wrote:
>>>>> I can boot into a CLANG v3.7 compiled kernel when lib/bitmap is
>>>>> compiled with GCC v4.9.
>>>> are you sure it's not lib/hweight.o instead? under gcc it's compiled
>>>> with special flags (CONFIG_ARCH_HWEIGHT_CFLAGS) which clang doesn't
>>>> support and we used to patch that out but i have no idea about the
>>>> current state of affairs.
>>> Hi pipacs :-),
>>> if I switch the compiler with the same llvmlinux-patchset and
>>> kernel-config GCC v4.9 builds fine.
>>> So, I am not sure if the CLANG v3.7 compiler is BROKEN when doing
>>> (always-)inlining functions.
>>> Can you give some aid, how to verify if it is a COMPILER problem or a
>>> kernel-side one?
>>> - Sedat -
>>> LLVMLinux mailing list
>>> LLVMLinux at lists.linuxfoundation.org
More information about the LLVMLinux