ppc64: ELFv2: Load TOC value in system call stub

This fixes a segmentation fault in the system call's error handling path with
dynamically-linked binaries on PowerPC64 little endian.  The system call stub
wasn't loading up r2 with the appropriate TOC value in its global entry point.

The r2 setup code comes from the FUNC_START macro in gcc [1] and an equivalent
one can also be found in the LOCALENTRY macro in glibc [2].

On the ELFv2 ABI (see [1]):
 - The global entry point is expected to load up r2 with the appropriate TOC
   value for this function.
 - The local entry point expects r2 to be set up to the current TOC.

The problem happened with dynamically-linked binaries because:
 - the system call is an indirect call (via global entry point) from the binary
   to the shared library, landing in the syscall stub  (which didn't load up r2
   with the TOC of the shared library)
 - its branch to __syscall_error is a direct call (via local entry point) within
   the shared library, landing in the function (which expects r2 to be set up to
   that TOC)
 - when the function attempts to store errno (in an address relative to the TOC),
   that address incorrectly pointed to a read-only segment -- segmentation fault.

The problem didn't happen with statically-linked binaries because the TOC value
wasn't different on that case.

Thanks and credits to Alan Modra and Ulrich Weigand, for helping with this and
pointing out the solution.

[1] https://gcc.gnu.org/ml/gcc-patches/2013-11/msg01141.html
[2] https://www.sourceware.org/ml/libc-alpha/2013-11/msg00315.html

Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Gbp-Pq: Name ppc64el-load-toc-syscall-stub.patch

Fix minimal mv to work across fs

This is the use case in initramfs to keep data from /run to /root/run
before calling switch_root().

copy_file() doesn't yet catch EINTR, but that seems less of an issue
in initramfs.

copy_file() and much logic out of copy() is from Ulrich Dangel.
Thank you for the collaboration on this blocker for
http://bugs.debian.org/627808

While we are it require move to have mv at least 2 arguments passed.

Signed-off-by: Ulrich Dangel <uli@spamt.net>
Signed-off-by: maximilian attems <max@stro.at>
[bwh: This is no longer needed by initramfs-tools starting with version 0.121,
 so can be dropped after the stretch release]

Gbp-Pq: Name Fix-minimal-mv-to-work-across-fs

multiarch-include-path

Gbp-Pq: Name multiarch-include-path

Fix klibc Debian specific build trouble

Simply remove the headers_install invocation and rely on linux-libc-dev.

With these changes:

(the extra chmod was needed to allow for umask > 022) I could compile,
link and run this program:

#include <unistd.h>

int main(void)
{
write(1, "Hello world\n", 12);
return 0;
}

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[ added multi arch support ]
Signed-off-by: Colin Watson <cjwatson@ubuntu.com>
Signed-off-by: maximilian attems <max@stro.at>
[ fixed cross building ]
Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Gbp-Pq: Name klibc-linux-libc-dev

klibc (2.0.4-9+rpi1) stretch-staging; urgency=medium

  [changes brought forward from 2.0.4-2+rpi1 by Peter Michael Green <plugwash@p10link.net> at Wed, 26 Nov 2014 22:01:00 +0000]
  * Change compiler settings to values suitable for raspberry pi

[dgit import unpatched klibc 2.0.4-9+rpi1]

Import klibc_2.0.4-9+rpi1.debian.tar.xz

[dgit import tarball klibc 2.0.4-9+rpi1 klibc_2.0.4-9+rpi1.debian.tar.xz]

Import klibc_2.0.4.orig.tar.gz

[dgit import orig klibc_2.0.4.orig.tar.gz]