POSIX defines the = operator, but not ==. Fix the few places where we incorrectly used ==. (cherry picked from commit b2d4456b333970ab4cb01ed8045b9a8d2c4832f3) (cherry picked from commit e2c17de539da301c96afa4181347c63eb94d99b1)
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) (cherry picked from commit a07df04187284a7993d890d5164a4433cebfd930)
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) (cherry picked from commit 740e642e32f600afd95d1bddcfd3a961e46a9472)
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) (cherry picked from commit 5fc92dc17d6a2eb6420cef33d8d6bd3a84bb968c)
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) (cherry picked from commit 942c502aca15983fde794e4465adbcf42b51c379)
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) (cherry picked from commit d87bf6412b4cb0a5cd174d746eb596158075a5bb)
The defensive copy is not needed because the name may not alias the output buffer. (cherry picked from commit 317b199b4aff8cfa27f2302ab404d2bb5032b9a4) (cherry picked from commit 883dceebc8f11921a9890211a4e202e5be17562f)
Since commit 44d20bca52ace85850012b0ead37b360e3ecd96e (Implement second fallback mode for DNS requests), there is a code path which returns early, before *resplen2 is initialized. This happens if the name server address is immediately recognized as invalid (because of lack of protocol support, or if it is a broadcast address such 255.255.255.255, or another invalid address). If this happens and *resplen2 was non-zero (which is the case if a previous query resulted in a failure), __libc_res_nquery would reuse an existing second answer buffer. This answer has been previously identified as unusable (for example, it could be an NXDOMAIN response). Due to the presence of a second answer, no name server switching will occur. The result is a name resolution failure, although a successful resolution would have been possible if name servers have been switched and queries had proceeded along the search path. The above paragraph still simplifies the situation. Before glibc 2.23, if the second answer needed malloc, the stub resolver would still attempt to reuse the second answer, but this is not possible because __libc_res_nsearch has freed it, after the unsuccessful call to __libc_res_nquerydomain, and set the buffer pointer to NULL. This eventually leads to an assertion failure in __libc_res_nquery: /* Make sure both hp and hp2 are defined */ assert((hp != NULL) && (hp2 != NULL)); If assertions are disabled, the consequence is a NULL pointer dereference on the next line. Starting with glibc 2.23, as a result of commit e9db92d3acfe1822d56d11abcea5bfc4c41cf6ca (CVE-2015-7547: getaddrinfo() stack-based buffer overflow (Bug 18665)), the second answer is always allocated with malloc. This means that the assertion failure happens with small responses as well because there is no buffer to reuse, as soon as there is a name resolution failure which triggers a search for an answer along the search path. This commit addresses the issue by ensuring that *resplen2 is initialized before the send_dg function returns. This commit also addresses a bug where an invalid second reply is incorrectly returned as a valid to the caller. (cherry picked from commit b66d837bb5398795c6b0f651bd5a5d66091d8577) (cherry picked from commit 5a1a5f0dd2744044801c91bf2588444c29cda533)
The number of currently defined nameservers is stored in ->nscount, whereas ->_u._ext.nscount is set by __libc_res_nsend only after local initializations. (cherry picked from commit 5e7fdabd7df1fc6c56d104e61390bf5a6b526c38) (cherry picked from commit e5d560e0e7f621b5cde4bcbbac424f8b2742395a)
Since libmvec_nonshared.a may be linked into shared objects, ALIAS_IMPL should use PIC relocation. [BZ #19590] * sysdeps/x86_64/fpu/svml_finite_alias.S (ALIAS_IMPL): Use PIC relocation. (cherry picked from commit a5df3210a641c175138052037fcdad34298bfa4d) (cherry picked from commit 2b8ab5c3f618e4d9e0a9147c24f8cf6bbf35a1d8)