[Bug runtime/12645] exelib.exp failures (and hung stapio's) on s390x

["jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=12645

Josh Stone <jistone at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jistone at redhat dot com

--- Comment #5 from Josh Stone <jistone at redhat dot com> 2011-04-18 23:48:36 UTC ---
The prelink may be shifting things in a particularly bad way, but I suspect
that even the non-prelinked mode is still wrong.

(In reply to comment #4)
> Here's a run (with a non-prelinked .so) adding DEBUG_TASK_FINDER_VMA:
> [...]
> __stp_utrace_task_finder_target_syscall_exit:1435: tsk 2227 found mmap(0x0), returned 0x20000005000
> __stp_call_mmap_callbacks:611: pid 2227, a/l/o/p/path 0x20000005000  0x2000  0x0  r-xp  /root/s390x/libuprobeslibgcc-O3default-prelink-debug.so
> stap_uprobe_mmap_found:292: +mmap X pid 2227 path /root/s390x/libuprobeslibgcc-O3default-prelink-debug.so addr 0000020000005000 length 8192 offset (null) stf 000003c0018895f0 000003c0018895f0 path /root/s390x/libuprobeslibgcc-O3default-prelink-debug.so
> stap_uprobe_change_plus:67: +uprobe spec 1 idx 1 process uprobesgcc-O3de[2227] addr 0000020000005614 pp process("/root/s390x/libuprobeslibgcc-O3default-prelink-debug.so").statement(0x614)
> __stp_utrace_task_finder_target_syscall_exit:1435: tsk 2227 found mmap(0x0), returned 0x20000006000
> __stp_call_mmap_callbacks:611: pid 2227, a/l/o/p/path 0x20000006000  0x1000  0x0  rwxp  /root/s390x/libuprobeslibgcc-O3default-prelink-debug.so
> stap_uprobe_mmap_found:292: +mmap X pid 2227 path /root/s390x/libuprobeslibgcc-O3default-prelink-debug.so addr 0000020000006000 length 4096 offset (null) stf 000003c0018895f0 000003c0018895f0 path /root/s390x/libuprobeslibgcc-O3default-prelink-debug.so
> stap_uprobe_change_plus:67: +uprobe spec 1 idx 2 process uprobesgcc-O3de[2227] addr 0000020000006614 pp process("/root/s390x/libuprobeslibgcc-O3default-prelink-debug.so").statement(0x614)
> stap_uprobe_mmap_found:307: +mmap W pid 2227 path /root/s390x/libuprobeslibgcc-O3default-prelink-debug.so addr 0000020000006000 length 4096 offset (null) stf 000003c0018895f0 000003c0018895f0 path /root/s390x/libuprobeslibgcc-O3default-prelink-debug.so

Note how the .so is being mapped twice, once at 0x20000005000 r-xp, then at
0x20000006000 rwxp.  This corresponds to the text and data mappings for the
shared object.  So we'd expect to see +uprobes only on the first mapping, then
+semaphore on the second.

The first thing I noticed in the code is that stap_uprobe_change_plus() doesn't
consider the given offset much, except to compute the relocated
sdt_sem_address.  But here that doesn't even matter, as both mappings have
offset zero.  The LOAD headers I got from the .so are:

  Type Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg
Align
  LOAD 0x000000 0x0000000006400000 0x0000000006400000 0x00079c 0x00079c R E
0x1000
  LOAD 0x0007a0 0x00000000064017a0 0x00000000064017a0 0x000200 0x000218 RW 
0x1000

Since the offsets are both in the same 4k-aligned region, they both get mmap
offset 0, though the VirtAddr is padded to compensate.

So, I think stap_uprobe_change_plus() really ought to be considering the offset
in its address computation, and we should also not even attempt uprobes for
writeable mappings.

Beyond that, I think there may still be some oddness with the semaphores, as
-p3 shows the .so sdt_sem_offset=0x6400000, which looks more like a relocation
address.  And it would certainly be nice to better understand why failure here
ends up locking up stapio and the module shutdown path.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.