summaryrefslogtreecommitdiff
path: root/dev-util/valgrind/files
diff options
context:
space:
mode:
authorV3n3RiX <venerix@redcorelinux.org>2018-09-08 10:50:14 +0100
committerV3n3RiX <venerix@redcorelinux.org>2018-09-08 10:50:14 +0100
commit3f71901f8c228f4de570abed1831ce3ee425343e (patch)
treea2dcd300d05ef8a2ec275b44a92a9d85bd3baa24 /dev-util/valgrind/files
parent12bb627384ddfd47382b9f1b6464481a58d01ebb (diff)
gentoo resync 08.09.2018
Diffstat (limited to 'dev-util/valgrind/files')
-rw-r--r--dev-util/valgrind/files/valgrind-3.13.0-accept-read-only-PT_LOAD-segments-and-rodata.patch95
-rw-r--r--dev-util/valgrind/files/valgrind-3.13.0-ignore-further-mappings-after-read-all-debuginfo.patch70
2 files changed, 165 insertions, 0 deletions
diff --git a/dev-util/valgrind/files/valgrind-3.13.0-accept-read-only-PT_LOAD-segments-and-rodata.patch b/dev-util/valgrind/files/valgrind-3.13.0-accept-read-only-PT_LOAD-segments-and-rodata.patch
new file mode 100644
index 000000000000..41f73b43f351
--- /dev/null
+++ b/dev-util/valgrind/files/valgrind-3.13.0-accept-read-only-PT_LOAD-segments-and-rodata.patch
@@ -0,0 +1,95 @@
+See https://bugs.gentoo.org/664882
+
+From 64aa729bfae71561505a40c12755bd6b55bb3061 Mon Sep 17 00:00:00 2001
+From: Mark Wielaard <mark@klomp.org>
+Date: Thu, 12 Jul 2018 13:56:00 +0200
+Subject: [PATCH] Accept read-only PT_LOAD segments and .rodata.
+
+The new binutils ld -z separate-code option creates multiple read-only
+PT_LOAD segments and might place .rodata in a non-executable segment.
+
+Allow and keep track of separate read-only segments and allow a readonly
+page with .rodata section.
+
+Based on patches from Tom Hughes <tom@compton.nu> and
+H.J. Lu <hjl.tools@gmail.com>.
+
+https://bugs.kde.org/show_bug.cgi?id=395682
+---
+ coregrind/m_debuginfo/debuginfo.c | 2 --
+ coregrind/m_debuginfo/readelf.c | 34 +++++++++++++++++++++++--------
+ 3 files changed, 27 insertions(+), 10 deletions(-)
+
+--- a/coregrind/m_debuginfo/debuginfo.c
++++ b/coregrind/m_debuginfo/debuginfo.c
+@@ -957,9 +957,7 @@
+ # error "Unknown platform"
+ # endif
+
+-# if defined(VGP_x86_darwin) && DARWIN_VERS >= DARWIN_10_7
+ is_ro_map = seg->hasR && !seg->hasW && !seg->hasX;
+-# endif
+
+ # if defined(VGO_solaris)
+ is_rx_map = seg->hasR && seg->hasX && !seg->hasW;
+--- a/coregrind/m_debuginfo/readelf.c
++++ b/coregrind/m_debuginfo/readelf.c
+@@ -1785,7 +1785,7 @@
+ Bool loaded = False;
+ for (j = 0; j < VG_(sizeXA)(di->fsm.maps); j++) {
+ const DebugInfoMapping* map = VG_(indexXA)(di->fsm.maps, j);
+- if ( (map->rx || map->rw)
++ if ( (map->rx || map->rw || map->ro)
+ && map->size > 0 /* stay sane */
+ && a_phdr.p_offset >= map->foff
+ && a_phdr.p_offset < map->foff + map->size
+@@ -1816,6 +1816,16 @@
+ i, (UWord)item.bias);
+ loaded = True;
+ }
++ if (map->ro
++ && (a_phdr.p_flags & (PF_R | PF_W | PF_X))
++ == PF_R) {
++ item.exec = False;
++ VG_(addToXA)(svma_ranges, &item);
++ TRACE_SYMTAB(
++ "PT_LOAD[%ld]: acquired as ro, bias 0x%lx\n",
++ i, (UWord)item.bias);
++ loaded = True;
++ }
+ }
+ }
+ if (!loaded) {
+@@ -2083,17 +2093,25 @@
+ }
+ }
+
+- /* Accept .rodata where mapped as rx (data), even if zero-sized */
++ /* Accept .rodata where mapped as rx or rw (data), even if zero-sized */
+ if (0 == VG_(strcmp)(name, ".rodata")) {
+- if (inrx && !di->rodata_present) {
+- di->rodata_present = True;
++ if (!di->rodata_present) {
+ di->rodata_svma = svma;
+- di->rodata_avma = svma + inrx->bias;
++ di->rodata_avma = svma;
+ di->rodata_size = size;
+- di->rodata_bias = inrx->bias;
+ di->rodata_debug_svma = svma;
+- di->rodata_debug_bias = inrx->bias;
+- /* NB was 'inrw' prior to r11794 */
++ if (inrx) {
++ di->rodata_avma += inrx->bias;
++ di->rodata_bias = inrx->bias;
++ di->rodata_debug_bias = inrx->bias;
++ } else if (inrw) {
++ di->rodata_avma += inrw->bias;
++ di->rodata_bias = inrw->bias;
++ di->rodata_debug_bias = inrw->bias;
++ } else {
++ BAD(".rodata");
++ }
++ di->rodata_present = True;
+ TRACE_SYMTAB("acquiring .rodata svma = %#lx .. %#lx\n",
+ di->rodata_svma,
+ di->rodata_svma + di->rodata_size - 1);
diff --git a/dev-util/valgrind/files/valgrind-3.13.0-ignore-further-mappings-after-read-all-debuginfo.patch b/dev-util/valgrind/files/valgrind-3.13.0-ignore-further-mappings-after-read-all-debuginfo.patch
new file mode 100644
index 000000000000..5b47512c1553
--- /dev/null
+++ b/dev-util/valgrind/files/valgrind-3.13.0-ignore-further-mappings-after-read-all-debuginfo.patch
@@ -0,0 +1,70 @@
+Follow up for valgrind-3.13.0-accept-read-only-PT_LOAD-segments-and-rodata.patch.
+
+From e752326cc050803c3bcfde1f8606bead66ff9642 Mon Sep 17 00:00:00 2001
+From: Julian Seward <jseward@acm.org>
+Date: Tue, 14 Aug 2018 10:13:46 +0200
+Subject: [PATCH] VG_(di_notify_mmap): once we've read debuginfo for an object,
+ ignore all further mappings. n-i-bz.
+
+Once we've read debuginfo for an object, ignore all further mappings. If we
+don't do that, applications that mmap in their own objects to inspect them for
+whatever reason, will cause "irrelevant" mappings to be recorded in the
+object's fsm.maps table. This can lead to serious problems later on.
+
+This has become necessary because 64aa729bfae71561505a40c12755bd6b55bb3061 of
+Thu Jul 12 2018 (the fix for bug 395682) started recording readonly segments
+in the fsm.maps table, where before they were ignored.
+---
+ coregrind/m_debuginfo/debuginfo.c | 29 ++++++++++++++++++++++++++++-
+ 1 file changed, 28 insertions(+), 1 deletion(-)
+
+diff --git a/coregrind/m_debuginfo/debuginfo.c b/coregrind/m_debuginfo/debuginfo.c
+index c36d498..55c05cb 100644
+--- a/coregrind/m_debuginfo/debuginfo.c
++++ b/coregrind/m_debuginfo/debuginfo.c
+@@ -1200,6 +1200,32 @@ ULong VG_(di_notify_mmap)( Addr a, Bool allow_SkFileV, Int use_fd )
+ di = find_or_create_DebugInfo_for( filename );
+ vg_assert(di);
+
++ /* Ignore all mappings for this filename once we've read debuginfo for it.
++ This avoids the confusion of picking up "irrelevant" mappings in
++ applications which mmap their objects outside of ld.so, for example
++ Firefox's Gecko profiler.
++
++ What happens in that case is: the application maps the object "ro" for
++ whatever reason. We record the mapping di->fsm.maps. The application
++ later unmaps the object. However, the mapping is not removed from
++ di->fsm.maps. Later, when some other (unrelated) object is mapped (via
++ ld.so) into that address space, we first unload any debuginfo that has a
++ mapping intersecting that area. That means we will end up incorrectly
++ unloading debuginfo for the object with the "irrelevant" mappings. This
++ causes various problems, not least because it can unload the debuginfo
++ for libc.so and so cause malloc intercepts to become un-intercepted.
++
++ This fix assumes that all mappings made once we've read debuginfo for
++ an object are irrelevant. I think that's OK, but need to check with
++ mjw/thh. */
++ if (di->have_dinfo) {
++ if (debug)
++ VG_(printf)("di_notify_mmap-4x: "
++ "ignoring mapping because we already read debuginfo "
++ "for DebugInfo* %p\n", di);
++ return 0;
++ }
++
+ if (debug)
+ VG_(printf)("di_notify_mmap-4: "
+ "noting details in DebugInfo* at %p\n", di);
+@@ -1220,7 +1246,8 @@ ULong VG_(di_notify_mmap)( Addr a, Bool allow_SkFileV, Int use_fd )
+ di->fsm.have_ro_map |= is_ro_map;
+
+ /* So, finally, are we in an accept state? */
+- if (di->fsm.have_rx_map && di->fsm.have_rw_map && !di->have_dinfo) {
++ vg_assert(!di->have_dinfo);
++ if (di->fsm.have_rx_map && di->fsm.have_rw_map) {
+ /* Ok, so, finally, we found what we need, and we haven't
+ already read debuginfo for this object. So let's do so now.
+ Yee-ha! */
+--
+2.9.3
+