commit 4ae4592f1106e941023a5768d34c2381cc869631
Author: Frank Ch. Eigler <fche@redhat.com>
Date:   Wed Aug 21 19:29:45 2019 -0400

    PR23879, PR24875: fix task-finder-vma on f29+
    
    It was reported & rediscovered that some vma-dependent runtime
    facilities have been broken: @vma() and *ubacktrace().  It turns out
    that modern gcc/ld.so links/loads binaries in slightly different ways
    than older toolchains.  Specifically, the first page of ELF files is
    now loaded only r--p instead of r-xp protection flags.  The
    _stp_vma_mmap_cb() routine now accepts the r--p case too.  It now
    ignores the flags entirely.

diff --git a/runtime/vma.c b/runtime/vma.c
index 7021725..02f9bf8 100644
--- a/runtime/vma.c
+++ b/runtime/vma.c
@@ -157,10 +157,15 @@ static int _stp_vma_mmap_cb(struct stap_task_finder_target *tgt,
 	dbug_task_vma(1,
 		  "mmap_cb: tsk %d:%d path %s, addr 0x%08lx, length 0x%08lx, offset 0x%lx, flags 0x%lx\n",
 		  tsk->pid, tsk->tgid, path, addr, length, offset, vm_flags);
-	// We are only interested in the first load of the whole module that
-	// is executable. We register whether or not we know the module,
+        
+	// We used to be only interested in the first load of the whole module that
+	// is executable.  But with modern enough gcc/ld.so, executables are mapped
+        // in more small pieces (r--p,r-xp,rw-p, instead of r-xp, rw-p).  To establish
+        // the virtual base address, we initially look for an offset=0 mapping.
+        //
+        // We register whether or not we know the module,
 	// so we can later lookup the name given an address for this task.
-	if (path != NULL && offset == 0 && (vm_flags & VM_EXEC)
+	if (path != NULL && offset == 0
 	    && stap_find_vma_map_info(tsk, addr, NULL, NULL, NULL, NULL) != 0) {
 		for (i = 0; i < _stp_num_modules; i++) {
 			// PR20433: papering over possibility of NULL pointers