[Bug uprobes/11249] uprobes fails on glibc get-pc-thunk call insn probe

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

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

--- Comment #11 from Josh Stone <jistone at redhat dot com> 2010-11-17 00:19:44 UTC ---
Belated update... later in that thread, I theorized that the GPF may be the
CPU's check that the call target is within the segment boundaries.  Roland
helped me dig into this, and after "sysctl -w kernel.print-fatal-signals=1", I
got:

> [  259.933657] #GPF(0[seg:0]) at bfb19020, CPU#0.
> [  259.934104] exec_limit: bfb1a000, user_cs: 0000fb19/00cbfb00.
> [  259.934707] stap/1684: potentially unexpected fatal signal 11.
> [  259.934709] code at bfb19020: e8 05 ea 00 00 8d 85 a8 fa ff ff 89 5c 24 08 89 
> [  259.934768] Pid: 1684, comm: stap Not tainted 2.6.35.6-45.fc14.i686 #1 /Bochs
> [  259.934771] EIP: 0073:[<bfb19020>] EFLAGS: 00010346 CPU: 0
> [  259.934779] EIP is at 0xbfb19020
> [  259.934781] EAX: 00000000 EBX: bfb169f4 ECX: bfb16950 EDX: bfb163e0
> [  259.934783] ESI: 00000002 EDI: 00000000 EBP: bfb16938 ESP: bfb16140
> [  259.934785]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
> [  259.934788] Process stap (pid: 1684, ti=dce12000 task=ddcf9940 task.ti=dce12000)
> [  259.935379] 
> [  259.935381] Call Trace:
> [  259.937563] Task died at uprobe probepoint:  pid/tgid = 1684/1684, probepoint = 0x80538f6

Notice in particular the exec_limit at bfb1a000.  Our instruction at bfb19020
is 5 bytes, "e8 05 ea 00 00 : call +0xea05", which puts the call target at
0xbfb27a2a.  So indeed, we appear to be leaving the segment.  That's before
uprobes corrects the IP, of course, but the CPU doesn't give us that chance.

This is on a non-PAE kernel.  Roland informed me that i686.PAE and x86_64
kernels don't put any bounds on the code segment, so I tried on a PAE kernel
and could not reproduce the issue. (And we already knew x86_64 was ok).

(In reply to comment #4)
> I was using 2.6.29.4-167.fc11.i686.PAE in my analysis.
> 
> Whats interesting is if we run a 2.6.33-rc4 git kernel from branch
> utrace-gdbstub-uprobes from location git://web.elastic.org/~fche/utrace-ext.git
> on the same machine, the problem disappears.

Srikar's PAE result casts this into doubt, unless in F11 times the PAE kernel
still kept segment limits.  Or he misreported. ;)  But I tried on F12-14 and
RHEL5, and consistently the non-PAE would fail while the PAE worked fine. 
RHEL6 is always PAE, and also works fine.

So - if we care about non-PAE kernels, we'll need to either refuse to probes
these relative instructions, or figure out a pre_ssout correction to keep the
target in bounds.  But at least on i686.PAE and x86_64, it seems ok.

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