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

ARC: build: add boot_targets to PHONY

2021-01-23T14:38:16+00:00

[ Upstream commit 0cfccb3c04934cdef42ae26042139f16e805b5f7 ]

The top-level boot_targets (uImage and uImage.*) should be phony
targets. They just let Kbuild descend into arch/arc/boot/ and create
files there.

If a file exists in the top directory with the same name, the boot
image will not be created.

You can confirm it by the following steps:

  $ export CROSS_COMPILE=
  $ make -s ARCH=arc defconfig all   # vmlinux will be built
  $ touch uImage.gz
  $ make ARCH=arc uImage.gz
  CALL    scripts/atomic/check-atomics.sh
  CALL    scripts/checksyscalls.sh
  CHK     include/generated/compile.h
  # arch/arc/boot/uImage.gz is not created

Specify the targets as PHONY to fix this.

Signed-off-by: Masahiro Yamada 
Signed-off-by: Vineet Gupta 
Signed-off-by: Sasha Levin

ARC: change defconfig defaults to ARCv2

2018-12-08T12:05:08+00:00

commit b7cc40c32a8bfa6f2581a71747f6a7d491fe43ba upstream.

Change the default defconfig (used with 'make defconfig') to the ARCv2
nsim_hs_defconfig, and also switch the default Kconfig ISA selection to
ARCv2.

This allows several default defconfigs (e.g. make defconfig, make
allnoconfig, make tinyconfig) to all work with ARCv2 by default.

Note since we change default architecture from ARCompact to ARCv2
it's required to explicitly mention architecture type in ARCompact
defconfigs otherwise ARCv2 will be implied and binaries will be
generated for ARCv2.

Cc:  # 4.4.x
Signed-off-by: Kevin Hilman 
Signed-off-by: Alexey Brodkin 
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

ARC: build: Don't set CROSS_COMPILE in arch's Makefile

2018-10-20T07:51:32+00:00

commit 40660f1fcee8d524a60b5101538e42b1f39f106d upstream.

There's not much sense in doing that because if user or
his build-system didn't set CROSS_COMPILE we still may
very well make incorrect guess.

But as it turned out setting CROSS_COMPILE is not as harmless
as one may think: with recent changes that implemented automatic
discovery of __host__ gcc features unconditional setup of
CROSS_COMPILE leads to failures on execution of "make xxx_defconfig"
with absent cross-compiler, for more info see [1].

Set CROSS_COMPILE as well gets in the way if we want only to build
.dtb's (again with absent cross-compiler which is not really needed
for building .dtb's), see [2].

Note, we had to change LIBGCC assignment type from ":=" to "="
so that is is resolved on its usage, otherwise if it is resolved
at declaration time with missing CROSS_COMPILE we're getting this
error message from host GCC:

| gcc: error: unrecognized command line option -mmedium-calls
| gcc: error: unrecognized command line option -mno-sdata

[1] http://lists.infradead.org/pipermail/linux-snps-arc/2018-September/004308.html
[2] http://lists.infradead.org/pipermail/linux-snps-arc/2018-September/004320.html

Signed-off-by: Alexey Brodkin 
Cc: Masahiro Yamada 
Cc: Rob Herring 
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

ARC: build: Get rid of toolchain check

2018-10-20T07:51:32+00:00

commit 615f64458ad890ef94abc879a66d8b27236e733a upstream.

This check is very naive: we simply test if GCC invoked without
"-mcpu=XXX" has ARC700 define set. In that case we think that GCC
was built with "--with-cpu=arc700" and has libgcc built for ARC700.

Otherwise if ARC700 is not defined we think that everythng was built
for ARCv2.

But in reality our life is much more interesting.

1. Regardless of GCC configuration (i.e. what we pass in "--with-cpu"
   it may generate code for any ARC core).

2. libgcc might be built with explicitly specified "--mcpu=YYY"

That's exactly what happens in case of multilibbed toolchains:
 - GCC is configured with default settings
 - All the libs built for many different CPU flavors

I.e. that check gets in the way of usage of multilibbed
toolchains. And even non-multilibbed toolchains are affected.
OpenEmbedded also builds GCC without "--with-cpu" because
each and every target component later is compiled with explicitly
set "-mcpu=ZZZ".

Acked-by: Rob Herring 
Signed-off-by: Alexey Brodkin 
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

ARC: Explicitly add -mmedium-calls to CFLAGS

2018-08-24T11:12:26+00:00

[ Upstream commit 74c11e300c103af47db5b658fdcf28002421e250 ]

GCC built for arc*-*-linux has "-mmedium-calls" implicitly enabled by default
thus we don't see any problems during Linux kernel compilation.
----------------------------->8------------------------
arc-linux-gcc -mcpu=arc700 -Q --help=target | grep calls
  -mlong-calls                          [disabled]
  -mmedium-calls                        [enabled]
----------------------------->8------------------------

But if we try to use so-called Elf32 toolchain with GCC configured for
arc*-*-elf* then we'd see the following failure:
----------------------------->8------------------------
init/do_mounts.o: In function 'init_rootfs':
do_mounts.c:(.init.text+0x108): relocation truncated to fit: R_ARC_S21W_PCREL
against symbol 'unregister_filesystem' defined in .text section in fs/filesystems.o

arc-elf32-ld: final link failed: Symbol needs debug section which does not exist
make: *** [vmlinux] Error 1
----------------------------->8------------------------

That happens because neither "-mmedium-calls" nor "-mlong-calls" are enabled in
Elf32 GCC:
----------------------------->8------------------------
arc-elf32-gcc -mcpu=arc700 -Q --help=target | grep calls
  -mlong-calls                          [disabled]
  -mmedium-calls                        [disabled]
----------------------------->8------------------------

Now to make it possible to use Elf32 toolchain for building Linux kernel
we're explicitly add "-mmedium-calls" to CFLAGS.

And since we add "-mmedium-calls" to the global CFLAGS there's no point in
having per-file copies thus removing them.

Signed-off-by: Alexey Brodkin 
Signed-off-by: Vineet Gupta 

Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'arc-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc

2016-11-12T00:51:50+00:00

Pull ARC fixes from Vineet Gupta:

 - mmap handler for dma ops as generic handler no longer works for us
   [Alexey]

 - Fixes for EZChip platform [Noam]

 - Fix RTC clocksource driver build issue

 - ARC IRQ handling fixes [Yuriy]

 - Revert a recent makefile change which doesn't go well with oldish
   tools out in the wild

* tag 'arc-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
  ARCv2: MCIP: Use IDU_M_DISTRI_DEST mode if there is only 1 destination core
  ARC: IRQ: Do not use hwirq as virq and vice versa
  ARC: [plat-eznps] set default baud for early console
  ARC: [plat-eznps] remove IPI clear from SMP operations
  Revert "ARC: build: retire old toggles"
  ARC: timer: rtc: implement read loop in "C" vs. inline asm
  ARC: change return value of userspace cmpxchg assist syscall
  arc: Implement arch-specific dma_map_ops.mmap
  ARC: [SMP] avoid overriding present cpumask
  ARC: Enable PERF_EVENTS in nSIM driven platforms

Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"

2016-11-11T16:45:08+00:00

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 e74fc973b6e5 ("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 877417e6ffb9 ("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 6e8d666e9253 ("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: Arnd Bergmann 
Signed-off-by: Linus Torvalds

Revert "ARC: build: retire old toggles"

2016-11-08T17:23:52+00:00

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 c3005475889c7c730638f95d13be3360f0b33e98.

ARC: build: retire old toggles

2016-10-28T17:10:27+00:00

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: Vineet Gupta

ARC: dw2 unwind: add infrastructure for adding cfi pseudo ops to asm

2016-09-30T21:48:22+00:00

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: Vineet Gupta