Hi,

I have just uploaded a fixed package to DELAYED/4, you will find the
diff attached. Please feel free to ask for it to be removed from the
delayed queue if you prefer to get the package fixed another way (in
a timely manner though).

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurel...@aurel32.net                 http://www.aurel32.net
diff -Nru klibc-2.0.4/debian/changelog klibc-2.0.4/debian/changelog
--- klibc-2.0.4/debian/changelog	2014-09-11 21:27:30.000000000 +0200
+++ klibc-2.0.4/debian/changelog	2014-09-17 16:12:28.000000000 +0200
@@ -1,3 +1,14 @@
+klibc (2.0.4-1.1) unstable; urgency=medium
+
+  [ Aurelien Jarno ]
+  * Non-maintainer upload.
+
+  [ Mauricio Faria de Oliveira ]
+  * Add ppc64el-load-toc-syscall-stub.patch: fix segfault on dynamically-linked
+    binaries on ppc64el. (Closes: #749060)
+
+ -- Aurelien Jarno <aure...@debian.org>  Wed, 17 Sep 2014 13:47:02 +0200
+
 klibc (2.0.4-1) unstable; urgency=medium
 
   * New upstream release (x86, readlink) (closes: #760587)
diff -Nru klibc-2.0.4/debian/patches/ppc64el-load-toc-syscall-stub.patch klibc-2.0.4/debian/patches/ppc64el-load-toc-syscall-stub.patch
--- klibc-2.0.4/debian/patches/ppc64el-load-toc-syscall-stub.patch	1970-01-01 01:00:00.000000000 +0100
+++ klibc-2.0.4/debian/patches/ppc64el-load-toc-syscall-stub.patch	2014-09-17 16:11:23.000000000 +0200
@@ -0,0 +1,55 @@
+Subject: [klibc] [PATCH] ppc64: ELFv2: Load TOC value in system call stub
+Origin: http://www.zytor.com/pipermail/klibc/2014-September/003603.html
+
+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 at linux.vnet.ibm.com>
+---
+ usr/klibc/arch/ppc64/sysstub.ph |    3 +++
+ 1 files changed, 3 insertions(+), 0 deletions(-)
+
+diff --git a/usr/klibc/arch/ppc64/sysstub.ph b/usr/klibc/arch/ppc64/sysstub.ph
+index b3f6e38..a0c6d41 100644
+--- a/usr/klibc/arch/ppc64/sysstub.ph
++++ b/usr/klibc/arch/ppc64/sysstub.ph
+@@ -18,6 +18,9 @@ sub make_sysstub($$$$$@) {
+ #if _CALL_ELF == 2
+ 	.type ${fname},\@function
+ ${fname}:
++0:	addis	2,12,(.TOC.-0b)\@ha
++	addi	2,2,(.TOC.-0b)\@l
++	.localentry ${fname},.-${fname}
+ #else
+ 	.section ".opd","aw"
+ 	.balign 8
+-- 
+1.7.1
diff -Nru klibc-2.0.4/debian/patches/series klibc-2.0.4/debian/patches/series
--- klibc-2.0.4/debian/patches/series	2014-09-11 21:20:45.000000000 +0200
+++ klibc-2.0.4/debian/patches/series	2014-09-17 16:11:23.000000000 +0200
@@ -4,3 +4,4 @@
 insmod
 multiarch-include-path
 Fix-minimal-mv-to-work-across-fs
+ppc64el-load-toc-syscall-stub.patch

Reply via email to