linux-stable.git/arch/arc/Makefile, branch linux-4.7.y

Disable "maybe-uninitialized" warning globally

2016-09-30T08:12:43+00:00

commit 6e8d666e925333c55378e8d5540a8a9ee0eea9c5 upstream.

Several build configurations had already disabled this warning because
it generates a lot of false positives.  But some had not, and it was
still enabled for "allmodconfig" builds, for example.

Looking at the warnings produced, every single one I looked at was a
false positive, and the warnings are frequent enough (and big enough)
that they can easily hide real problems that you don't notice in the
noise generated by -Wmaybe-uninitialized.

The warning is good in theory, but this is a classic case of a warning
that causes more problems than the warning can solve.

If gcc gets better at avoiding false positives, we may be able to
re-enable this warning.  But as is, we're better off without it, and I
want to be able to see the *real* warnings.

Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ARC: unwind: ensure that .debug_frame is generated (vs. .eh_frame)

2016-06-28T04:12:28+00:00

With recent binutils update to support dwarf CFI pseudo-ops in gas, we
now get .eh_frame vs. .debug_frame. Although the call frame info is
exactly the same in both, the CIE differs, which the current kernel
unwinder can't cope with.

This broke both the kernel unwinder as well as loadable modules (latter
because of a new unhandled relo R_ARC_32_PCREL from .rela.eh_frame in
the module loader)

The ideal solution would be to switch unwinder to .eh_frame.
For now however we can make do by just ensureing .debug_frame is
generated by removing -fasynchronous-unwind-tables

 .eh_frame    generated with -gdwarf-2 -fasynchronous-unwind-tables
 .debug_frame generated with -gdwarf-2

Fixes STAR 9001058196

Cc: stable@vger.kernel.org
Signed-off-by: Vineet Gupta

Fix typos

2016-05-30T04:37:32+00:00

Signed-off-by: Andrea Gelmini 
Signed-off-by: Vineet Gupta

ARC: Add eznps platform to Kconfig and Makefile

2016-05-09T04:02:33+00:00

This commit should be left last since only now eznps platform
is in state which one can actually use.
Signed-off-by: Noam Camus

ARC: build: Turn off -Wmaybe-uninitialized for ARC gcc 4.8

2016-03-18T10:52:36+00:00

linux-next has been reporting gazillion warnings for ARC build and
I finally decided to take a bite:

http://kisskb.ellerman.id.au/kisskb/buildresult/12638735/

Most of the them are due to -Wmaybe-uninitialized

| ../kernel/sysctl.c: In function '__do_proc_doulongvec_minmax':
| ../kernel/sysctl.c:1928:12: warning: 'p' may be used uninitialized in this function [-Wmaybe-uninitialized]
|   ret = tmp - *buf;
|            ^
| ../kernel/sysctl.c:2342:29: note: 'p' was declared here
|  char *kbuf = NULL, *p;
|                     ^
| ...
| ...

Cursory look at code seemed fine and a definite gcc false positive in say
kernel/sysctl.c

Mystery was why only for ARC (and not with ARM linaro toolchain based
off same gcc 4.8). Turns out that -O3 (default for ARC) triggers these
and if I enable -O3 for ARM kernel build, I see the same splat.

I initially wanted to disable this only for gcc 4.8, but Arnd reported
it is seen even on gcc 6.0 for ARM with -O3. Thus better to disable
this independent of gcc version.

Cc: Claudiu Zissulescu 
Cc: Arnd Bergmann 
Cc: Michal Marek 
Cc: Geert Uytterhoeven 
Cc: linux-kbuild@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Vineet Gupta

ARC: build: Better way to detect ISA compatible toolchain

2016-03-12T06:28:30+00:00

ARC architecture has 2 instruction sets: ARCompact/ARCv2.
While same gcc supports compiling for either (using appropriate toggles),
we can't use the same toolchain to build kernel because libgcc needs
to be unique and the toolchian (uClibc based) is not multilibed.

uClibc toolchain is convenient since it allows all userspace and
kernel to be built with a single install for an ISA.

This however means 2 gnu installs (with same triplet prefix) are needed
for building for 2 ISA and need to be in PATH.
As developers we keep switching the builds, but would occassionally fail
to update the PATH leading to usage of wrong tools. And this would only
show up at the end of kernel build when linking incompatible libgcc.

So the initial solution was to have gcc define a special preprocessor macro
DEFAULT_CPU_xxx which is unique for default toolchain configuration.
Claudiu proposed using grep for an existing preprocessor macro which is
again uniquely defined per ISA.

Cc: Michal Marek 
Suggested-by: Claudiu Zissulescu 
Signed-off-by: Vineet Gupta

ARC: [BE] Select correct CROSS_COMPILE prefix

2016-03-11T09:29:54+00:00

This allows CONFIG_CPU_BIG_ENDIAN=y to build correctly out of the box,
w/o any other tweaks.

Cc: Noam Camus 
Cc: Alexey Brodkin 
Cc: Anton Kolesov 
Signed-off-by: Vineet Gupta

ARC: Assume multiplier is always present

2016-02-18T12:00:03+00:00

It is unlikely that designs running Linux will not have multiplier.
Further the current support is not complete as tool don't generate a
multilib w/o multiplier.

Signed-off-by: Vineet Gupta

ARC: Fix linking errors with CONFIG_MODULE + CONFIG_CC_OPTIMIZE_FOR_SIZE

2015-12-21T07:31:19+00:00

At -Os, ARC gcc generates millicode thunk for function prologue/epilogue,
which are served by libgcc.

Modules historically are NOT linked with libgcc to avoid code bloat, reducing
runtime relocation fixups etc. I even once tried doing that but got lost
in makefile intricacies.

This means modules at -Os don't get the millicode thunks, causing build
failures below:

| MODPOST 5 modules
| ERROR: "__ld_r13_to_r18" [crypto/sha256_generic.ko] undefined!
| ERROR: "__ld_r13_to_r18_ret" [crypto/sha256_generic.ko] undefined!
| ERROR: "__st_r13_to_r18" [crypto/sha256_generic.ko] undefined!
| ERROR: "__ld_r13_to_r17_ret" [crypto/sha256_generic.ko] undefined!
| ERROR: "__st_r13_to_r17" [crypto/sha256_generic.ko] undefined!
| ERROR: "__ld_r13_to_r16_ret" [crypto/sha256_generic.ko] undefined!
| ERROR: "__st_r13_to_r16" [crypto/sha256_generic.ko] undefined!
|....
|....

Workaround that by inhibiting millicode thunks for loadable modules

Fixes STAR 9000641864:
("Linux built with optimizations for size emits errors for modules")

Reported-by: Anton Kolesov 
Cc: Michal Marek 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Vineet Gupta

arc: use common make variables for dtb builds

2015-10-27T21:12:13+00:00

Use dtb-y and always make variables to build dtbs instead of explicit
dtbs rule. This is in preparation to support building all dtbs.

Signed-off-by: Rob Herring 
Acked-by: Vineet Gupta