Backport of df1cf48777fe4cd81ad7fb09ecbe5b31432b7c1c. * stdlib/setenv.c (unsetenv): Fix ambiguous 'else'. * nis/nis_call.c (nis_server_cache_add): Likewise.
On s390/s390x backtrace(buffer, size) returns the series of called functions until "makecontext_ret" and additional entries (up to "size") with "makecontext_ret". GDB-backtrace is also warning: "Backtrace stopped: previous frame identical to this frame (corrupt stack?)" To reproduce this scenario you have to setup a new context with makecontext() and activate it with setcontext(). See e.g. cf() function in testcase stdlib/tst-makecontext.c. Or see bug in libgo "Bug 66303 - runtime.Caller() returns infinitely deep stack frames on s390x " (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66303). This patch omits the cfi_startproc/cfi_endproc directives in ENTRY/END macro of __makecontext_ret. Thus no frame information is generated in .eh_frame and backtrace stops after __makecontext_ret. There is also no .eh_frame info for _start or thread_start functions. ChangeLog: [BZ #18508] * stdlib/Makefile ($(objpfx)tst-makecontext3): Depend on $(libdl). * stdlib/tst-makecontext.c (cf): Test if _Unwind_Backtrace is not called infinitely times. (backtrace_helper): New function. (trace_arg): New struct. (st1): Enlarge stack size. * sysdeps/unix/sysv/linux/s390/s390-32/__makecontext_ret.S: (__makecontext_ret): Omit cfi_startproc and cfi_endproc. * sysdeps/unix/sysv/linux/s390/s390-64/__makecontext_ret.S: Likewise. (cherry picked from commit 890b7a4b33d482b5c768ab47d70758b80227e9bc)
This patch uses sigprocmask(SIG_SETMASK) instead of SIG_BLOCK in setcontext, swapcontext. (cherry picked from commit 2e807f29595eb5b1e5d0decc6e356a3562ecc58e)
POSIX defines the = operator, but not ==. Fix the few places where we incorrectly used ==. (cherry picked from commit b2d4456b333970ab4cb01ed8045b9a8d2c4832f3)
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)
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)
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)
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)
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)
When using sln on some filesystems which return 64-bit inodes, the stat call might fail during install like so: .../elf/sln .../elf/symlink.list /lib32/libc.so.6: invalid destination: Value too large for defined data type /lib32/ld-linux.so.2: invalid destination: Value too large for defined data type Makefile:104: recipe for target 'install-symbolic-link' failed Switch to using stat64 all the time to avoid this. URL: https://bugs.gentoo.org/576396 (cherry picked from commit f5e753c8c3a18a1e3c715dd11bf4dc341b5c481f)