[COMMITED,2.22,2.21,2.20] S390: Save and restore fprs/vrs while resolving symbols.

  Hi,

I`ve applied the "S390: Save and restore fprs/vrs while resolving 
symbols." patch to release branch 2.20 - 2.22. The other patches are 
needed for preparation.

[PATCH 1/5] S390: Add hwcaps value for vector facility.

The HWCAP_S390_VX flag in hwcap field of auxiliary vector indicates
if the vector facility is available and the kernel is aware of it.
This can be tested with LD_SHOW_AUXV=1 <prog>.
Currently it does not show te, because it was not incremented
by commit "S/390: Add hwcap value for transactional execution.".
Thus _DL_HWCAP_COUNT is incremented by two.

ChangeLog:

	* sysdeps/s390/dl-procinfo.c (_dl_s390_platforms): Add vector flag.
	* sysdeps/s390/dl-procinfo.h: Add vector capability.
	* sysdeps/unix/sysv/linux/s390/bits/hwcap.h (HWCAP_S390_VX): Define.

(cherry picked from commit 4e28fa80886c71e6aaf85016b82ce981c0f12e6d)

[PATCH 2/5] S390: Add new s390 platform.

The new IBM z13 is added to platform string array.
The macro _DL_PLATFORMS_COUNT is incremented to 8,
because it was not incremented by commit
"S/390: Sync AUXV capabilities and archs with kernel".

ChangeLog:

	* sysdeps/s390/dl-procinfo.c (_dl_s390_cap_flags): Add z13.
	* sysdeps/s390/dl-procinfo.h (_DL_PLATFORMS_COUNT): Increased.

(cherry picked from commit a1b0488fc9df3d895a2e5eefbcd348d3f7fe0e52)

[PATCH 3/5] S390: configure check for vector instruction support in
  assembler.

The S390 specific test checks if the assembler has support for the new z13
vector instructions by compiling a vector instruction. The .machine and
.machinemode directives are needed to compile the vector instruction without
-march=z13 option on 31/64 bit.
On success the macro HAVE_S390_VX_ASM_SUPPORT is defined. This macro is used
to determine if the optimized functions can be build without compile errors.
If the used assembler lacks vector support, then a warning is dumped while
configuring and only the common code functions are build.

The z13 instruction support was introduced in
"[Committed] S/390: Add support for IBM z13."
(https://sourceware.org/ml/binutils/2015-01/msg00197.html)

ChangeLog:

	* config.h.in (HAVE_S390_VX_ASM_SUPPORT): New macro undefine.
	* sysdeps/s390/configure.ac: Add test for S390 vector instruction
	assembler support.
	* sysdeps/s390/configure: Regenerated.

(cherry picked from commit 4f0a1cea34c05fb2acc16f1a2d291f53230eb4fb)

[PATCH 4/5] S390: Save and restore fprs/vrs while resolving symbols.

On s390, no fpr/vrs were saved while resolving a symbol
via _dl_runtime_resolve/_dl_runtime_profile.

According to the abi, the fpr-arguments are defined as call clobbered.
In leaf-functions, gcc 4.9 and newer can use fprs for saving/restoring gprs
instead of saving them to the stack.
If gcc do this in one of the resolver-functions, then the floating point
arguments of a library-function are invalid for the first 
library-function-call.
Thus, this patch saves/restores the fprs around the resolving code.

The same could occur for vector registers. Furthermore an ifunc-resolver
could also clobber the vector/floating point argument registers.
Thus this patch provides the further variants _dl_runtime_resolve_vx/
_dl_runtime_profile_vx, which are used if the kernel claims, that
we run on a machine with vector registers.

Furthermore, if _dl_runtime_profile calls _dl_call_pltexit,
the pointers to inregs-/outregs-structs were setup invalid.
Now they point to the correct location in the stack-frame.
Before branching back to the caller, the return values are now
restored instead of containing the return values of the
_dl_call_pltexit() call.
On s390-32, an endless loop occurs if _dl_call_pltexit() should be called.
Now, this code-path branches to this function instead of just after the
preceding basr-instruction.

ChangeLog:

	* sysdeps/s390/s390-32/dl-trampoline.S: Include dl-trampoline.h twice
	to create a non-vector/vector version for _dl_runtime_resolve and
	_dl_runtime_profile. Move implementation to ...
	* sysdeps/s390/s390-32/dl-trampoline.h: ... here.
	(_dl_runtime_resolve) Save and restore fpr/vrs.
	(_dl_runtime_profile) Save and restore vrs and fix some issues
	if _dl_call_pltexit is called.
	* sysdeps/s390/s390-32/dl-machine.h (elf_machine_runtime_setup):
	Choose the correct resolver function if running on a machine with vx.
	* sysdeps/s390/s390-64/dl-trampoline.S: Include dl-trampoline.h twice
	to create a non-vector/vector version for _dl_runtime_resolve and
	_dl_runtime_profile. Move implementation to ...
	* sysdeps/s390/s390-64/dl-trampoline.h: ... here.
	(_dl_runtime_resolve) Save and restore fpr/vrs.
	(_dl_runtime_profile) Save and restore vrs and fix some issues
	* sysdeps/s390/s390-64/dl-machine.h: (elf_machine_runtime_setup):
	Choose the correct resolver function if running on a machine with vx.

(cherry picked from commit 4603c51ef7989d7eb800cdd6f42aab206f891077
and commit d8a012c5c9e4bfc1b8db2bc6deacb85b44a2e1eb)

[PATCH 5/5] S390: Extend structs La_s390_regs / La_s390_retval with
  vector-registers.

Starting with z13, vector registers can also occur as argument registers.
Thus the passed input/output register structs for
la_s390_[32|64]_gnu_plt[enter|exit] functions should reflect those new
registers. This patch extends these structs La_s390_regs and La_s390_retval
and adjusts _dl_runtime_profile() to handle those fields in case of
running on a z13 machine.

ChangeLog:

	* sysdeps/s390/bits/link.h: (La_s390_vr) New typedef.
	(La_s390_32_regs): Append vector register lr_v24-lr_v31.
	(La_s390_64_regs): Likewise.
	(La_s390_32_retval): Append vector register lrv_v24.
	(La_s390_64_retval): Likeweise.
	* sysdeps/s390/s390-32/dl-trampoline.h (_dl_runtime_profile):
	Handle extended structs La_s390_32_regs and La_s390_32_retval.
	* sysdeps/s390/s390-64/dl-trampoline.h (_dl_runtime_profile):
	Handle extended structs La_s390_64_regs and La_s390_64_retval.

(cherry picked from commit 5cdd1989d1d2f135d02e66250f37ba8e767f9772)

[COMMITED,2.22,2.21,2.20] S390: Save and restore fprs/vrs while resolving symbols.

Commit Message

Patch