Traditionally, we have always had warnings about uninitialized variables
enabled, as this is part of -Wall, and generally a good idea [1], but it
also always produced false positives, mainly because this is a variation
of the halting problem and provably impossible to get right in all cases
[2].

Various people have identified cases that are particularly bad for false
positives, and in commit e74fc973 ("Turn off -Wmaybe-uninitialized
when building with -Os"), I turned off the warning for any build that
was done with CC_OPTIMIZE_FOR_SIZE.  This drastically reduced the number
of false positive warnings in the default build but unfortunately had
the side effect of turning the warning off completely in 'allmodconfig'
builds, which in turn led to a lot of warnings (both actual bugs, and
remaining false positives) to go in unnoticed.

With commit 877417e6 ("Kbuild: change CC_OPTIMIZE_FOR_SIZE
definition") enabled the warning again for allmodconfig builds in v4.7
and in v4.8-rc1, I had finally managed to address all warnings I get in
an ARM allmodconfig build and most other maybe-uninitialized warnings
for ARM randconfig builds.

However, commit 6e8d666e ("Disable "maybe-uninitialized" warning
globally") was merged at the same time and disabled it completely for
all configurations, because of false-positive warnings on x86 that I had
not addressed until then.  This caused a lot of actual bugs to get
merged into mainline, and I sent several dozen patches for these during
the v4.9 development cycle.  Most of these are actual bugs, some are for
correct code that is safe because it is only called under external
constraints that make it impossible to run into the case that gcc sees,
and in a few cases gcc is just stupid and finds something that can
obviously never happen.

I have now done a few thousand randconfig builds on x86 and collected
all patches that I needed to address every single warning I got (I can
provide the combined patch for the other warnings if anyone is
interested), so I hope we can get the warning back and let people catch
the actual bugs earlier.

This reverts the change to disable the warning completely and for now
brings it back at the "make W=1" level, so we can get it merged into
mainline without introducing false positives.  A follow-up patch enables
it on all levels unless some configuration option turns it off because
of false-positives.

Link: https://rusty.ozlabs.org/?p=232 [1]
Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2]
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This has caused a bunch of build failures at a few sites, with GNU
2015.12 and older as the assembler seems to need -mlock to be able to
grok llock/scond instructions for ARC700 builds.
different places since the
older tools still seem to release
of tools which most people are using seem to trip with the -mlock flag
not being passed.

This reverts commit c3005475.

These are really ancient toggles and tools no longer require them to be
passed. This paves way for deprecating them in long run.
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

1. detect whether binutils supports the cfi pseudo ops
2. define conditional macros to generate the ops
3. define new ENTRY_CFI/END_CFI to annotate hand asm code.
   - Needed because we don't want to emit dwarf info in general ENTRY/END
     used by lowest level trap/exception/interrutp handlers as unwinder
     gets confused trying to unwind out of them. We want unwinder to
     instead stop when it hits onfo those routines
   - These provide minimal start/end cfi ops assuming routine doesn't
     touch stack memory/regs
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

In .debug_frame based unwinding regime, we used to force -gdwarf-2 since
kernel unwinder only claimed to handle dwarf 2. This changed since commit
6d0d5060 ("ARC: dw2 unwind: Don't bail for CIE.version != 1")
which added some support beyond dwarf 2, atleast to handle CIE != 1

The ill-effect of -gdwarf-2 is that it forces generation of .debug_*
sections, which bloats loadable modules .ko files. For the curious, this
doesn't affect vmlinx binary since linker script discards .debug_* but
same discard is not yet implemented for modules.

So it seems we can drop the -gdwarf-2 toggle, which should not be needed
anyways given that we now use .eh_frame based unwinding.

I've verified using GNU 2016.09-engo10 that the actual unwind info is
not different with or w/o this toggle - but the debug_* sections are
gone for good.

before
-----
arc-linux-readelf -S q_proc.ko-unwinding-1-eh_frame-switch | grep debug
  [15] .debug_info       PROGBITS        00000000 000300 00d08d 00 	0   0  1
  [16] .rela.debug_info  RELA            00000000 0162a0 008844 0c   I 29  15  4
  [17] .debug_abbrev     PROGBITS        00000000 00d38d 0005f8 00 	0   0  1
  [18] .debug_loc        PROGBITS        00000000 00d985 000070 00 	0   0  1
  [19] .rela.debug_loc   RELA            00000000 01eae4 0000c0 0c   I 29  18  4
  [20] .debug_aranges    PROGBITS        00000000 00d9f5 000040 00 	0   0  1
  [21] .rela.debug_arang RELA            00000000 01eba4 000030 0c   I 29  20  4
  [22] .debug_ranges     PROGBITS        00000000 00da35 000018 00 	0   0  1
  [23] .rela.debug_range RELA            00000000 01ebd4 000030 0c   I 29  22  4
  [24] .debug_line       PROGBITS        00000000 00da4d 000b5b 00 	0   0  1
  [25] .rela.debug_line  RELA            00000000 01ec04 0000cc 0c   I 29  24  4
  [26] .debug_str        PROGBITS        00000000 00e5a8 007831 01   MS 0   0  1

after
----
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

So finally after almost 8 years of dealing with .debug_frame, we are
finally switching to .eh_frame. The reason being stripped kernel
binaries had non-functional unwinder as .debug_frame was gone.
Also, in general .eh_frame seems more common way of doing unwinding.

This also folds a revert of f52e126c ("ARC: unwind: ensure that
.debug_frame is generated (vs. .eh_frame)") to ensure that we start
getting .eh_frame
Reported-by: NDaniel Mentz <danielmentz@google.com>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

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: NLinus Torvalds <torvalds@linux-foundation.org>

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: NVineet Gupta <vgupta@synopsys.com>

Signed-off-by: NAndrea Gelmini <andrea.gelmini@gelma.net>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

This commit should be left last since only now eznps platform
is in state which one can actually use.
Signed-off-by: NNoam Camus <noamc@ezchip.com>

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 <Claudiu.Zissulescu@synopsys.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-kbuild@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

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 <mmarek@suse.cz>
Suggested-by: NClaudiu Zissulescu <claziss@synopsys.com>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

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

Cc: Noam Camus <noamc@ezchip.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Anton Kolesov <akolesov@synosys.com>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

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: NVineet Gupta <vgupta@synopsys.com>

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: NAnton Kolesov <akolesov@synosys.com>
Cc: Michal Marek <mmarek@suse.cz>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

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: NRob Herring <robh@kernel.org>
Acked-by: NVineet Gupta <vgupta@synopsys.com>

Being highly configurable core ARC HS among other features might be
configured with or without DIV_REM_OPTION (hardware divider).

That option when enabled adds following instructions: div, divu, rem, remu.

By default ARC HS38 has this option enabled. So we add here possibility
to disable usage of hardware divider by compiler.
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

ARC kernels have historically been built with -O3, despite top level
Makefile defaulting to -O2. This was facilitated by implicitly ordering
of arch makefile include AFTER top level assigned -O2.

An upstream fix to top level a1c48bb1 ("Makefile: Fix unrecognized
cross-compiler command line options") changed the ordering, making ARC
-O3 defunct.

Fix that by NOT relying on any ordering whatsoever and use the proper
arch override facility now present in kbuild (ARCH_*FLAGS)

Depends-on: ("kbuild: Allow arch Makefiles to override {cpp,ld,c}flags")
Suggested-by: NMichal Marek <mmarek@suse.cz>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: stable@vger.kernel.org # 3.16+
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Reported-by: NGuenter Roeck <private@roeck-us.net>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

-no-ll64 is specific to ARCv2 ISA, and is obviously not supported by
older ARC gcc - in this case the one hosted by linux-next sanity build
service.

Ensure that it doesn't get included for ISA_ARCOMPACT
Reported-by: NGuenter Roeck <private@roeck-us.net>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

The notable features are:
    - SMP configurations of upto 4 cores with coherency
    - Optional L2 Cache and IO-Coherency
    - Revised Interrupt Architecture (multiple priorites, reg banks,
        auto stack switch, auto regfile save/restore)
    - MMUv4 (PIPT dcache, Huge Pages)
    - Instructions for
	* 64bit load/store: LDD, STD
	* Hardware assisted divide/remainder: DIV, REM
	* Function prologue/epilogue: ENTER_S, LEAVE_S
	* IRQ enable/disable: CLRI, SETI
	* pop count: FFS, FLS
	* SETcc, BMSKN, XBFU...
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

The AXS10x platforms consist of a mainboard with peripherals,
on which several daughter cards can be placed. The daughter cards
typically contain a CPU and memory.
Signed-off-by: NMischa Jonker <mjonker@synopsys.com>
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

* Remove remanants of legacy ARC FPGA platforms (AA4, ML509...)
* Only nsim simulation platform is left, rename platform accordingly
* AA4 DT stuff is compatible with nsim for ARC700 so rename it too
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

ARC GNU tools have had support for arc-linux-* driver for some time now.
This is functionally similar to arc-linux-uclibc-* but uclibc prefix
seemed weird at best when trying to compile the kernel itself.
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

* DWARF unwinder related
  + Force DWARF2 compliant .debug_frame (gcc 4.8 defaults to DWARF4
    which kernel unwinder can't grok).
  + Discard the additional .eh_frame generated
  + Discard the dwarf4 debug info generated by -gdwarf-2 for normal
    no debug case

* 4.8 already uses arc600 multilibs for -mno-mpy

* switch to using uclibc compiler (to get -mmedium-calls and -mno-sdata)
  and also since buildroot can only use 1 toolchain
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Infrastructure required to make the Linux kernel compile and boot on the
Abilis Systems TB10x series of SOCs based on ARC700 CPUs:
  - Kmake related files (Kconfig, Makefile, tb10x_defconfig)
  - TB10x platform initialisation
Signed-off-by: NChristian Ruppert <christian.ruppert@abilis.com>
Signed-off-by: NPierrick Hascoet <pierrick.hascoet@abilis.com>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

The existing uImage target always generates gzip compressed image which
drags bootup for some very slow FPGA customer boards.

So introduce seperate make targets:uImage.{bin,gz} with uncompressed
being default. Also tie gz generation to CONFIG_KERNEL_GZIP, which a
platform can select in it's Kconfig if it wishes gz to be default.
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

We do cross compiles for ARC Linux.
With gcc 4.7, a make defconfig spews out the following:

------------------->8--------------------------
make ARCH=arc defconfig
gcc: error: unrecognized command line option '-marc600'
gcc: error: unrecognized command line option '-mA7'
gcc: error: unrecognized command line option '-mno-sdata'
gcc: error: unrecognized command line option '-mno-mpy'
*** Default configuration is based on 'fpga_defconfig'
------------------->8--------------------------

This apparently is coming from LIBGCC line - which is strange to be
invoked for defconfig generation.
Reported-by: NAlexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

-Top level ARC makefile removes -I for platform headers
-asm/irq.h no longer includes plat/irq.h

-platform makefile adds -I for it's specfic platform headers
-platform code to directly include it's plat/irq.h

-Linker script needed plat/memmap.h for CCM info, already in .config
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

ARC common code to enable a SMP system + ISS provided SMP extensions.

ARC700 natively lacks SMP support, hence some of the core features are
are only enabled if SoCs have the necessary h/w pixie-dust. This
includes:
-Inter Processor Interrupts (IPI)
-Cache coherency
-load-locked/store-conditional
...

The low level exception handling would be completely broken in SMP
because we don't have hardware assisted stack switching. Thus a fair bit
of this code is repurposing the MMU_SCRATCH reg for event handler
prologues to keep them re-entrant.

Many thanks to Rajeshwar Ranga for his initial "major" contributions to
SMP Port (back in 2008), and to Noam Camus and Gilad Ben-Yossef for help
with resurrecting that in 3.2 kernel (2012).

Note that this platform code is again singleton design pattern - so
multiple SMP platforms won't build at the moment - this deficiency is
addressed in subsequent patches within this series.
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Rajeshwar Ranga <rajeshwar.ranga@gmail.com>
Cc: Noam Camus <noamc@ezchip.com>
Cc: Gilad Ben-Yossef <gilad@benyossef.com>

Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
Cc: Robert Richter <rric@kernel.org>
Cc: oprofile-list@lists.sf.net
Reviewed-by: NJames Hogan <james.hogan@imgtec.com>

Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

This is minimal infrastructure needed for devicetree work.
It uses an a sample "skeleton" devicetree - embedded in kernel image -
to print the board, manufacturer by parsing the top-level "compatible"
string.

As of now we don't need any additional "board" specific "machine_desc".

TODO: support interpreting the command line as boot-loader passed dtb
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: devicetree-discuss@lists.ozlabs.org
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: James Hogan <james.hogan@imgtec.com>
Reviewed-by: NRob Herring <rob.herring@calxeda.com>
Reviewed-by: NJames Hogan <james.hogan@imgtec.com>

Arnd in his review pointed out that arch Kconfig organisation has several
deficiencies:

* Build time entries for things which can be runtime extracted from DT
  (e.g. SDRAM size, core clk frequency..)
* Not multi-platform-image-build friendly (choice .. endchoice constructs)
* cpu variants support (750/770) is exclusive.

The first 2 have been fixed in subsequent patches.
Due to the nature of the 750 and 770, it is not possible to build for
both together, w/o special runtime glue code which would hurt
performance.
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Sam Ravnborg <sam@ravnborg.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>