08:20 <franks2> fche: https://paste.ubuntu.com/p/s7VnbdyF6H/ output from stap -t. Did not tel me a whole lot of stuff tho.

08:59 <franks2> fche: I'm not perticullary familiar with GDB.

09:02 <franks2> https://paste.ubuntu.com/p/nXcGb3YX4f/ info stap probes

09:16 <franks2> Were you able to get function__entry on your server?

11:50 <fche> franks2, couldn't trigger the apache2 php module with the couple of minutes I tried

11:51 <franks2> Hm. No output at all from stap?

11:51 <fche> nah, stap likes it fine

11:51 <fche> it's that I couldn't trigger any php7 http-module activity just then

11:51 <fche> so there were no hits of any sort

11:51 <franks2> Ah

11:52 <franks2> Even though thah readelf reported the same probes as I?

11:52 <fche> yup

11:52 <franks2> Thats weird :)

11:52 <fche> well just poor http sysadmining :) I think I am running php scripts via an external process, not mod_php7

11:53 <franks2> Ah, Okies

11:54 <franks2> I'm kind of at loss here. I'll try the mailing list I suppose. Thanks for your time

12:12 <fche> were you able to run gdb against the process that links in your php2.so ? tried breakpoints in the vicinity of the missing probe?

12:17 <franks2> fche: Im not too familair with gdb :(

12:18 <fche> aha

12:27 <franks2> https://paste.ubuntu.com/p/DMgcgvDKCk/

12:43 <franks2> Hm. (gdb) break -probe-stap request__startup. Does not make any hits. It does in stap tho.

12:54 <fche> stap scripts normally operate systemwide; gdb is limited to a process (or sometimes its future descendant hierarchy)

12:54 <fche> so with gdb you have to aim at the correct process; if you have a multi-process httpd with embedded mod_php7.so, the requests can get delegated to any of them :(

13:16 <franks2> https://paste.ubuntu.com/p/q6ZvNqmYTB/ Messing aruond in gdb

13:40 <fche> yeah you'd set a probe with the break command then let it continue / run

13:40 <fche> and it should get stopped when the breakpoint (sdt.h marker) is hit