[llvmlinux] "make test" for x86_64 target just hung there, why?
Sedat Dilek
sedat.dilek at gmail.com
Sat Sep 12 03:36:39 UTC 2015
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 [1] 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
file.
[ 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
#else
/* 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
#endif
#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
"always_inline".
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".
Thanks.
Regards,
- Sedat -
[1] 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
[2] 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?
>
> Regards,
> - Sedat -
> _______________________________________________
> LLVMLinux mailing list
> LLVMLinux at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/llvmlinux
More information about the LLVMLinux
mailing list