GitLab

I have no idea if this is correct. Clang would complain about the "I"
constraint being invalid and then crash. This workaround just lets me
move on to fix the next bug for now.

Clang complains about using val undefined which could happen if enum
value was corrupted.

Author: Mark Charlebois <charlebm@gmail.com>
Signed-off-by: Mark Charlebois <charlebm@gmail.com>

Add missing abort for arch aarch64.
Signed-off-by: Mark Charlebois <charlebm@gmail.com>

futex_init passes in uaddr = 0. The LLVM optimizer will see that *uaddr is 0, set the register
to xzr and compilation will fail.
Signed-off-by: Mark Charlebois <charlebm@gmail.com>

Make sure the return value in AARCH64 __xchg() and __cmpxchg() is initialized
in the default case of the switch so that we never return an uninitialized
value.
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
Signed-off-by: Behan Webster <behanw@converseincode.com>

Fix variable types for 64-bit inline assembly.
Signed-off-by: Mark Charlebois <charlebm@gmail.com>

Use current_stack_pointer() instead of a named register.
This change supports being able to compile the kernel with both gcc
and Clang.
Signed-off-by: Behan Webster <behanw@converseincode.com>

Use the frame pointer to calculate the location of thread info.
This change supports being able to compile the kernel with both gcc
and Clang.
Signed-off-by: Behan Webster <behanw@converseincode.com>

The existing code uses named registers to get the value of the stack pointer.
The new current_stack_pointer macro is more readable and allows for a central
portable implementation of how to get the stack pointer with ASM.  This change
supports being able to compile the kernel with both gcc and Clang.
Signed-off-by: Behan Webster <behanw@converseincode.com>

A macro to get the current stack pointer which allows for a single place in
which to do so with ASM. Before this named registers (a gcc extension) was used
to get the stack pointer. Using ASM is a more portable way of getting the stack
pointer which works with both gcc and clang.  This macro is of the same name
used in the X86 arch.
Signed-off-by: Behan Webster <behanw@converseincode.com>

Protect more options for arm with cc-option so that we don't get errors when
using clang instead of gcc.  Add more or different options when using clang as
well.

Author: Behan Webster <behanw@converseincode.com>
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
Signed-off-by: Behan Webster <behanw@converseincode.com>

These symbols are required when compiling the Linux kernel for arch ARM64 with
clang.

Author: Mark Charlebois <charlebm@gmail.com>
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
Signed-off-by: Behan Webster <behanw@converseincode.com>

Patch to prevent warning of a buggy compiler when using clang and
the ARM_UNWIND option.

Clang defines (at least on the current trunk) GNUC, GNUC_MINOR, and
GNUC_PATCHLEVEL to 4, 2, and 1 respectively.

This version of GCC gets flagged as buggy, but it isn't actually an
issue with clang so the patch will do what it did before unless clang
is defined and then it will not report the GCC version as an issue.
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
Signed-off-by: Behan Webster <behanw@converseincode.com>

The existing code uses named registers to get the value of the stack pointer.
The new current_stack_pointer macro is more readable and allows for a central
portable implementation of how to get the stack pointer with ASM.  This change
supports being able to compile the kernel with both gcc and Clang.
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Jan-Simon M??ller <dl9pf@gmx.de>

Use the frame pointer to calculate the start of the stack for current_thread_info()
The existing code uses the stack pointer to do this calculation.
Using the frame pointer yeilds the same value in a portable way.
This change supports being able to compile the kernel with gcc and Clang.
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Jan-Simon M??ller <dl9pf@gmx.de>

The existing code uses named registers to get the value of the stack pointer.
The new current_stack_pointer macro is more readable and allows for a central
portable implementation of how to get the stack pointer with ASM.  This change
supports being able to compile the kernel with both gcc and Clang.
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Jan-Simon M??ller <dl9pf@gmx.de>

The existing code uses named registers to get the value of the stack pointer.
The new current_stack_pointer macro is more readable and allows for a central
portable implementation of how to get the stack pointer with ASM. This change
supports being able to compile the kernel with both gcc and Clang.
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Jan-Simon M??ller <dl9pf@gmx.de>

Use the frame pointer to calculate the end of the stack for current_pt_regs()
The existing code uses the stack pointer to do this calculation.
Using the frame pointer yeilds the same value in a more portable way.
This change supports being able to compile the kernel with gcc and clang.
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Jan-Simon M??ller <dl9pf@gmx.de>

The current kernel code uses a named register to get the stack pointer which is
only supported in gcc. For clang an alternative is to use a macro to get the
current stack pointer using ASM (which is less efficient than a named
resgiter). Long term the LLVMLinux project is hoping to introduce a new
__builtin_stack_pointer() which will be added to both LLVM and gcc.

Author: Behan Webster <behanw@converseincode.com>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>

Protect more options for arm with cc-option so that we don't get errors when
using clang instead of gcc.  Add more or different options when using clang as
well.

Author: Behan Webster <behanw@converseincode.com>
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
Signed-off-by: Behan Webster <behanw@converseincode.com>

With compilers which follow the C99 standard (like modern versions of gcc and
clang), "extern inline" does the wrong thing (emits code for an externally
linkable version of the inline function). In this case using static inline
and removing the NULL version of return_address in return_address.c does
the right thing.
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>

With compilers which follow the C99 standard (like modern versions of gcc and
clang), "extern inline" does the wrong thing (emits code for an externally
linkable version of the inline function). "static inline" is the correct choice
instead.

Author: Behan Webster <behanw@converseincode.com>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>

These symbols are required when compiling the Linux kernel for arch ARM with
clang.

Author: Mark Charlebois <charlebm@gmail.com>
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
Signed-off-by: Behan Webster <behanw@converseincode.com>

Clang's intrinsics ignore -mregparm=3 when they fall back to calling the
out-of-line implementations. Putting the args on the stack when memcpy()
expects them in registers is not a recipe for a happy kernel.

This bites with -m32 too, so clang is presumably catastrophically
broken for the i386 kernel until this is fixed, unless I'm missing
something.

For information/testing only; do not apply. With this, I can use
'clang -m16' to build all the kernel's 16-bit code and get a successful
boot.
Not-signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Forward-ported-by: Jan-Simon Möller <dl9pf@gmx.de>

M16_CFLAGS does not work on CLANG 3.5 right now. While we investigate the issue
allow the upstreaming work to continue with the old CODE16GCC_CFLAGS.
Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>

Wrap -mno-80387 gcc options with cc-option so they don't break clang.
Signed-off-by: Behan Webster <behanw@converseincode.com>

which do not yet support -m16 which landed in 3.5svn
Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>

The clang integrated assembler (IA) doesn't support .code16, as a result we
turn it off and use gas instead.
Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>
Cc: PaX Team <pageexec@freemail.hu>

Add -no-integrated-as with cc-option. This is transparent for gcc.
We need it the boot-code as we don't inherit the global no-integrated-as.
Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>
Cc: PaX Team <pageexec@freemail.hu>

Along with gcc >= 4.3, clang also needs memcpy exported.
Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>
Cc: PaX Team <pageexec@freemail.hu>

Ignore the flags set in Kconfig for hweight if the compiler is clang.

This is also reported as LLVM PR9457

Author: Behan Webster <behanw@converseincode.com>
Signed-off-by: Behan Webster <behanw@converseincode.com>

The call to __builtin_log2 presumes there is a
double log2(double x) function defined in the kernel.

The call to hash_log is a call to hash_64 which is
defined in include/linux/hash.h

static __always_inline u64 hash_64(u64 val, unsigned int bits)

That means that __builtin_log2(NR_BG_LOCKS) is converting
NR_BG_LOCKS to a double and returning a double and then that
is converted to an unsigned int.

Using ilog2 is much more appropriate and efficient.

Another side effect of using __builtin_log2 is that is uses
__aeabi_* functions for ARM that require linking with libgcc.a.

Author: Mark Charlebois <charlebm@gmail.com>
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
Signed-off-by: Behan Webster <behanw@converseincode.com>

Both gcc (well, actually gnu as) and clang support the "-Wa,-gdwarf-2" option
(though clang does not support "-Wa,--gdwarf-2"). Since these flags are equivalent
in meaning, this patch uses the one which is better supported across compilers.
Signed-off-by: Behan Webster <behanw@converseincode.com>

Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This is the original VLAIS struct.

struct {
	struct shash_desc shash;
	char ctx[crypto_shash_descsize(tfm)];
} desc;

This patch instead allocates the appropriate amount of memory using an char
array.

The new code can be compiled with both gcc and clang.
Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Signed-off-by: Vinícius Tinti <viniciustinti@gmail.com>
Signed-off-by: Mark Charlebois <charlebm@gmail.com>

Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This is the original VLAIS struct.

struct {
	struct shash_desc shash;
	char ctx[crypto_shash_descsize(apparmor_tfm)];
} desc;

This patch instead allocates the appropriate amount of memory using an
char
array.

The new code can be compiled with both gcc and clang.
Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Signed-off-by: Vinícius Tinti <viniciustinti@gmail.com>
Signed-off-by: Mark Charlebois <charlebm@gmail.com>

The use of variable length arrays in structs (VLAIS) in the Linux Kernel code
precludes the use of compilers which don't implement VLAIS (for instance the
Clang compiler). This patch instead allocates the appropriate amount of memory
using an char array.
Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Cc: pageexec@freemail.hu

Replaced non-standard C use of Variable Length Arrays In Structs (VLAIS) in
xt_repldata.h with a C99 compliant flexible array member and then calculated
offsets to the other struct members. These other members aren't referenced by
name in this code, however this patch maintains the same memory layout and
padding as was previously accomplished using VLAIS.

Had the original structure been ordered differently, with the entries VLA at
the end, then it could have been a flexible member, and this patch would have
been a lot simpler. However since the data stored in this structure is
ultimately exported to userspace, the order of this structure can't be changed.

This patch makes no attempt to change the existing behavior, merely the way in
which the current layout is accomplished using standard C99 constructs. As such
the code can now be compiled with either gcc or clang.

This version of the patch removes the trailing alignment that the VLAIS
structure would allocate in order to simplify the patch.

Author: Mark Charlebois <charlebm@gmail.com>
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Signed-off-by: Vinícius Tinti <viniciustinti@gmail.com>

Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This is the original VLAIS struct.

struct {
	struct aead_request     req;
	u8                      priv[crypto_aead_reqsize(tfm)];
} aead_req;

This patch instead allocates the appropriate amount of memory using an char
array.

The new code can be compiled with both gcc and clang.
Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Signed-off-by: Vinícius Tinti <viniciustinti@gmail.com>
Signed-off-by: Mark Charlebois <charlebm@gmail.com>