From a3d12927af145439f44e00777d3ead139cbf2c60 Mon Sep 17 00:00:00 2001
From: Jan Kratochvil <jan.kratochvil@redhat.com>
Date: Fri, 3 May 2013 03:43:06 +0200
Subject: [PATCH] Fix gcore for vDSO (on ppc64).

---
 gdb-vdso-gcore.patch | 56 ++++++++++++++++++++++++++++++++++++++++++++
 gdb.spec             |  9 ++++++-
 2 files changed, 64 insertions(+), 1 deletion(-)
 create mode 100644 gdb-vdso-gcore.patch

diff --git a/gdb-vdso-gcore.patch b/gdb-vdso-gcore.patch
new file mode 100644
index 0000000..4fdbc81
--- /dev/null
+++ b/gdb-vdso-gcore.patch
@@ -0,0 +1,56 @@
+http://sourceware.org/ml/gdb-patches/2013-05/msg00042.html
+Subject: [patch] Fix gcore for vDSO (on ppc64)
+
+Hi,
+
+on ppc64 GNU/Linux one gets in live process or kernel-generated core file:
+
+#0  0x00003fff9e946b3c in __pause_nocancel () from /lib64/libc.so.6
+#1  0x000000001000080c in handle_alrm (signo=14) at small.c:16
+#2  <signal handler called>
+#3  0x00003fff9e946b3c in __pause_nocancel () from /lib64/libc.so.6
+#4  0x0000000010000914 in main (argc=2, argv=0x3fffcd00dec8) at small.c:32
+
+while with gcore generated core file one gets:
+
+#0  0x00003fff9e946b3c in __pause_nocancel () from /lib64/libc.so.6
+#1  0x000000001000080c in handle_alrm (signo=14) at small.c:16
+#2  0x00003fff9ea70448 in ?? ()
+#3  0x0000000010000914 in main (argc=2, argv=0x3fffcd00dec8) at small.c:32
+
+This is because on ppc64 GNU/Linux the signal handler frame is in vDSO (and
+not in libc as on x86_64 GNU/Linux).  And if one has kernel-debuginfo
+installed GDB gcore thinks it can omit the vDSO page from core file.
+
+As vDSO cannot be reliably found from link_map it should be rather fully
+present in the core file.  Which also gcore_create_callback tries to do but it
+gets mistaken by the separate debug info.
+
+It seems pretty obvious patch to me.
+
+
+Thanks,
+Jan
+
+
+gdb/
+2013-05-03  Jan Kratochvil  <jan.kratochvil@redhat.com>
+
+	* gcore.c (gcore_create_callback): Ignore sections with
+	separate_debug_objfile_backlink != NULL.
+
+--- gdb-7.6-orig/gdb/gcore.c	2013-01-01 07:32:42.000000000 +0100
++++ gdb-7.6/gdb/gcore.c	2013-05-03 03:31:34.795312996 +0200
+@@ -428,8 +428,9 @@ gcore_create_callback (CORE_ADDR vaddr,
+ 
+ 	     This BFD was synthesized from reading target memory,
+ 	     we don't want to omit that.  */
+-	  if (((vaddr >= start && vaddr + size <= end)
+-	       || (start >= vaddr && end <= vaddr + size))
++	  if (objfile->separate_debug_objfile_backlink == NULL
++	      && ((vaddr >= start && vaddr + size <= end)
++	          || (start >= vaddr && end <= vaddr + size))
+ 	      && !(bfd_get_file_flags (abfd) & BFD_IN_MEMORY))
+ 	    {
+ 	      flags &= ~(SEC_LOAD | SEC_HAS_CONTENTS);
+
diff --git a/gdb.spec b/gdb.spec
index 0762d8b..f99843c 100644
--- a/gdb.spec
+++ b/gdb.spec
@@ -36,7 +36,7 @@ Version: 7.6
 
 # The release always contains a leading reserved number, start it at 1.
 # `upstream' is not a part of `name' to stay fully rpm dependencies compatible for the testing.
-Release: 25%{?dist}
+Release: 26%{?dist}
 
 License: GPLv3+ and GPLv3+ with exceptions and GPLv2+ and GPLv2+ with exceptions and GPL+ and LGPLv2+ and BSD and Public Domain
 Group: Development/Debuggers
@@ -566,6 +566,9 @@ Patch818: gdb-rhbz795424-bitpos-lazyvalue.patch
 #=fedoratest
 Patch832: gdb-rhbz947564-findvar-assertion-frame-failed-testcase.patch
 
+# Fix gcore for vDSO (on ppc64).
+Patch834: gdb-vdso-gcore.patch
+
 %if 0%{!?rhel:1} || 0%{?rhel} > 6
 # RL_STATE_FEDORA_GDB would not be found for:
 # Patch642: gdb-readline62-ask-more-rh.patch
@@ -887,6 +890,7 @@ find -name "*.info*"|xargs rm -f
 %patch817 -p1
 %patch818 -p1
 %patch832 -p1
+%patch834 -p1
 
 %patch393 -p1
 %if 0%{!?el5:1} || 0%{?scl:1}
@@ -1390,6 +1394,9 @@ fi
 %endif # 0%{!?el5:1} || "%{_target_cpu}" == "noarch"
 
 %changelog
+* Fri May  3 2013 Jan Kratochvil <jan.kratochvil@redhat.com> - 7.6-26.fc19
+- Fix gcore for vDSO (on ppc64).
+
 * Sat Apr 27 2013 Jan Kratochvil <jan.kratochvil@redhat.com> - 7.6-25.fc19
 - Fix false "Unknown error 512" on x32 (H.J. Lu, BZ 956883).