[Bug uprobes/10324] New: x86-64 uprobes gives up on 0xf0 prefix (lock)

[Bug uprobes/10324] New: x86-64 uprobes gives up on 0xf0 prefix (lock)

[fche at redhat dot com]

When probing multithreading libraries like libpthread, uprobes
rejects instructions like this for probing.

   f0 64 0f b1 0c 25 c8    lock cmpxchg %ecx,%fs:0xc8

Jun 23 21:19:25 grid-wn353 kernel: Can't place uprobe at pid 21629 vaddr
0x2b8f90f09691: instruction type cannot be probed

-- 
           Summary: x86-64 uprobes gives up on 0xf0 prefix (lock)
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: uprobes
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: fche at redhat dot com


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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10324] x86-64 uprobes gives up on 0xf0 prefix (lock)

[srikar at linux dot vnet dot ibm dot com]

------- Additional Comments From srikar at linux dot vnet dot ibm dot com  2009-06-24 14:56 -------
From runtime/uprobes2/uprobes_x86.c  0xf0(lock prefix is documented as not
supported)
---------------------------------------------------------------------
 * others -- Do we need to support these?                                       
 * 0f - (floating-point?) prefetch instructions                                 
 * 07, 17, 1f - pop es, pop ss, pop ds                                          
 * 26, 2e, 36, 3e - es:, cs:, ss:, ds: segment prefixes --                      
 *      but 64 and 65 (fs: and gs:) seem to be used, so we support them         
 * 67 - addr16 prefix                                                           
 * ce - into                                                                    
 * f0 - lock prefix 
------------------------------------------------------------------------

-- 


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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10324] x86-64 uprobes gives up on 0xf0 prefix (lock)

[jkenisto at us dot ibm dot com]

------- Additional Comments From jkenisto at us dot ibm dot com  2009-06-24 21:47 -------
(In reply to comment #1)
> From runtime/uprobes2/uprobes_x86.c  0xf0(lock prefix is documented as not
> supported)
> ---------------------------------------------------------------------
>  * others -- Do we need to support these?                                       
...                
>  * f0 - lock prefix 
> ------------------------------------------------------------------------

It's unsupported because I was vaguely uncomfortable about it and have never
tested probing locked instructions.  You could certainly try it out by changing
the f0 bit from 0 to 1 in good_insns_32[] and good_insns_64[].

See PR #5273, "x86 arch_validate_probed_insn(): lighten up?"

-- 


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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10324] x86-64 uprobes gives up on 0xf0 prefix (lock)

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-06-24 22:09 -------

> It's unsupported because I was vaguely uncomfortable about it and have never
> tested probing locked instructions.  You could certainly try it out by changing
> the f0 bit from 0 to 1 in good_insns_32[] and good_insns_64[].

I wouldn't trust such an experiment, since "lock" is rich with
concurrency semantics, testing the correctness of the SSOL
emulation would not be trivial.

> See PR #5273, "x86 arch_validate_probed_insn(): lighten up?"

Yeah, if you like, CLOSE/DUPLICATE them.


-- 


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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10324] x86-64 uprobes gives up on 0xf0 prefix (lock)

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-08-13 17:47 -------


*** This bug has been marked as a duplicate of 5273 ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE


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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.