MicroMIPS kernels may be expected to run on microMIPS only cores which
don't support the normal MIPS instruction set, so be sure to pass the
-mmicromips flag through to the VDSO cflags.

Fixes: ebb5e78c ("MIPS: Initial implementation of a VDSO")
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: <stable@vger.kernel.org> # 4.4.x-
Patchwork: https://patchwork.linux-mips.org/patch/13349/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Avoid an aliasing issue causing a build error in VDSO:

In file included from include/linux/srcu.h:34:0,
                 from include/linux/notifier.h:15,
                 from ./arch/mips/include/asm/uprobes.h:9,
                 from include/linux/uprobes.h:61,
                 from include/linux/mm_types.h:13,
                 from ./arch/mips/include/asm/vdso.h:14,
                 from arch/mips/vdso/vdso.h:27,
                 from arch/mips/vdso/gettimeofday.c:11:
include/linux/workqueue.h: In function 'work_static':
include/linux/workqueue.h:186:2: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
  return *work_data_bits(work) & WORK_STRUCT_STATIC;
  ^
cc1: all warnings being treated as errors
make[2]: *** [arch/mips/vdso/gettimeofday.o] Error 1

with a CONFIG_DEBUG_OBJECTS_WORK configuration and GCC 5.2.0.  Include
`-fno-strict-aliasing' along with compiler options used, as required for
kernel code, fixing a problem present since the introduction of VDSO
with commit ebb5e78c ("MIPS: Initial implementation of a VDSO").

Thanks to Tejun for diagnosing this properly!
Signed-off-by: NMaciej W. Rozycki <macro@imgtec.com>
Reviewed-by: NJames Hogan <james.hogan@imgtec.com>
Fixes: ebb5e78c ("MIPS: Initial implementation of a VDSO")
Cc: Tejun Heo <tj@kernel.org>
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org # v4.3+
Patchwork: https://patchwork.linux-mips.org/patch/13357/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The genvdso program modifies the debug and stripped versions of the
VDSOs in place, and errors if the modification has already taken place.
Unfortunately this means that a rebuild which tries to rerun genvdso to
generate vdso*-image.c without also rebuilding vdso.so.dbg (for example
if genvdso.c is modified) hits a build error like this:

arch/mips/vdso/genvdso 'arch/mips/vdso/vdso.so.dbg' already contains a '.MIPS.abiflags' section

This is fixed by reorganising the rules such that unmodified .so files
have a .raw suffix, and these are copied in the same rule that runs
genvdso on the copies.

I.e. previously we had:

 cmd_vdsold:
  link objects -> vdso.so.dbg

 cmd_genvdso:
  strip vdso.so.dbg -> vdso.so
  run genvdso -> vdso-image.c
   and modify vdso.so.dbg and vdso.so in place

Now we have:

 cmd_vdsold:
  link objects -> vdso.so.dbg.raw

 a new cmd_objcopy based strip rule (inspired by ARM):
  strip vdso.so.dbg.raw -> vdso.so.raw

 cmd_genvdso:
  copy vdso.so.dbg.raw -> vdso.so.dbg
  copy vdso.so.raw -> vdso.so
  run genvdso -> vdso-image.c
   and modify vdso.so.dbg and vdso.so in place
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13250/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The ld-version.sh script doesn't handle versions with large (>= 10) 3rd
version components, because the 2nd component is only multiplied by 10
times that of the 3rd component.

For example the following version string:
GNU ld (Codescape GNU Tools 2015.06-05 for MIPS MTI Linux) 2.24.90

gives a bogus version number:
 20000000
+ 2400000
+  900000 = 23300000

Breakage, confusion and mole-whacking ensues.

Increase the multipliers of the first two version components by a factor
of 10 to give space for a 3rd components of up to 99, and update the
sole user of ld-ifversion (MIPS VDSO) accordingly.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Acked-by: NGuenter Roeck <linux@roeck-us.net>
Reviewed-by: NAndi Kleen <ak@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/11931/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Commit 2a037f31 ("MIPS: VDSO: Fix build error") tries to fix a build
error seen with binutils 2.24 and earlier. However, the fix does not work,
and again results in the already known build errors if the kernel is built
with an earlier version of binutils.

CC      arch/mips/vdso/gettimeofday.o
/tmp/ccnOVbHT.s: Assembler messages:
/tmp/ccnOVbHT.s:50: Error: can't resolve `_start' {*UND* section} - `L0 {.text section}
/tmp/ccnOVbHT.s:374: Error: can't resolve `_start' {*UND* section} - `L0 {.text section}
scripts/Makefile.build:258: recipe for target 'arch/mips/vdso/gettimeofday.o' failed
make[2]: *** [arch/mips/vdso/gettimeofday.o] Error 1

Fixes: 2a037f31 ("MIPS: VDSO: Fix build error")
Cc: Qais Yousef <qais.yousef@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/11926/Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Commit ebb5e78c ("MIPS: Initial implementation of a VDSO") introduced a
build error.

For MIPS VDSO to be compiled it requires binutils version 2.25 or above but
the check in the Makefile had inverted logic causing it to be compiled in if
binutils is below 2.25.

This fixes the following compilation error:

CC      arch/mips/vdso/gettimeofday.o
/tmp/ccsExcUd.s: Assembler messages:
/tmp/ccsExcUd.s:62: Error: can't resolve `_start' {*UND* section} - `L0' {.text section}
/tmp/ccsExcUd.s:467: Error: can't resolve `_start' {*UND* section} - `L0' {.text section}
make[2]: *** [arch/mips/vdso/gettimeofday.o] Error 1
make[1]: *** [arch/mips/vdso] Error 2
make: *** [arch/mips] Error 2

[ralf@linux-mips: Fixed Sergei's complaint on the formatting of the
cited commit and generally reformatted the log message.]
Signed-off-by: NQais Yousef <qais.yousef@imgtec.com>
Cc: alex@alex-smith.me.uk
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/11745/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Add an initial implementation of a proper (i.e. an ELF shared library)
VDSO. With this commit it does not export any symbols, it only replaces
the current signal return trampoline page. A later commit will add user
implementations of gettimeofday()/clock_gettime().

To support both new toolchains and old ones which don't generate ABI
flags section, we define its content manually and then use a tool
(genvdso) to patch up the section to have the correct name and type.
genvdso also extracts symbol offsets ({,rt_}sigreturn) needed by the
kernel, and generates a C file containing a "struct mips_vdso_image"
containing both the VDSO data and these offsets. This C file is
compiled into the kernel.

On 64-bit kernels we require a different VDSO for each supported ABI,
so we may build up to 3 different VDSOs. The VDSO to use is selected by
the mips_abi structure.

A kernel/user shared data page is created and mapped below the VDSO
image. This is currently empty, but will be used by the user time
function implementations which are added later.

[markos.chandras@imgtec.com:
- Add more comments
- Move abi detection in genvdso.h since it's the get_symbol function
that needs it.
- Add an R6 specific way to calculate the base address of VDSO in order
to avoid the branch instruction which affects performance.
- Do not patch .gnu.attributes since it's not needed for dynamic linking.
- Simplify Makefile a little bit.
- checkpatch fixes
- Restrict VDSO support for binutils < 2.25 for pre-R6
- Include atomic64.h for O32 variant on MIPS64]
Signed-off-by: NAlex Smith <alex.smith@imgtec.com>
Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
Cc: Matthew Fortune <matthew.fortune@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/11337/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>