fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 248 seconds]
hpt has joined #systemtap
nkambo_ has joined #systemtap
nkambo__ has quit [Ping timeout: 260 seconds]
irker496 has quit [Quit: transmission timeout]
slowfranklin has joined #systemtap
slowfranklin has quit [Quit: slowfranklin]
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 240 seconds]
slowfranklin has joined #systemtap
nkambo_ has joined #systemtap
nkambo__ has quit [Ping timeout: 240 seconds]
slowfranklin has quit [Quit: slowfranklin]
slowfranklin has joined #systemtap
orivej has joined #systemtap
orivej has quit [Read error: Connection reset by peer]
slowfranklin has joined #systemtap
hpt has quit [Quit: Lost terminal]
scox has quit [Ping timeout: 248 seconds]
orivej has joined #systemtap
orivej has quit [Ping timeout: 240 seconds]
gila has joined #systemtap
mjw has joined #systemtap
wcohen has quit [Remote host closed the connection]
scox has joined #systemtap
wcohen has joined #systemtap
drsmith_away is now known as drsmith
tromey has joined #systemtap
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 248 seconds]
nkambo_ has joined #systemtap
nkambo__ has quit [Ping timeout: 248 seconds]
nkambo_ has quit [Ping timeout: 240 seconds]
nkambo_ has joined #systemtap
nkambo__ has joined #systemtap
nkambo_ has quit [Ping timeout: 240 seconds]
nkambo_ has joined #systemtap
lindi- has quit [Remote host closed the connection]
<fche>
hm notice no dtrace.o listed in the whole build.log
<fche>
yeah methinks that original patch is incomplete somehow
<fche>
or something else about the pythong2 buildsystem broke ... @DTRACEOBJS@ should probably include Python/dtrace.o
<cstratak>
yep. the same file was there in previous builds (with the older version).
<fche>
the autoconf machinery tests dtrace -G ....
<cstratak>
will try some adjustments to the patch. Thanks a lot for the pointers
<fche>
I'd look at patch line area 17 ish
<fche>
something is fishy
<fche>
maybe it's fish
nkambo__ has joined #systemtap
mjw has joined #systemtap
nkambo_ has quit [Ping timeout: 248 seconds]
<cstratak>
so it seems the command 'if dtrace -G -o /dev/null -s $srcdir/Include/pydtrace.d 2>/dev/null' returns a non-zero status
<fche>
hm, hand-running the python configure here works for me on rawhide
mjw has quit [Ping timeout: 260 seconds]
mjw has joined #systemtap
<cstratak>
fche, the configure script will work but it will go to the 'Apple' case, and not at the first if statement ('Sun' case).
<lindi->
new openssl versions have hidden most of the internal structs from header files. I worked around this by copying internal headers to my stap script. could systemtap consider including some common struct definitions?
<fche>
cstratak, yeah, it shouldn't
<lindi->
(I have a script that logs various TLS parameters systemwide)
<fche>
lindi-, neat. with debuginfo, stap should be able to get the struct definitions out of the object files pretty easily
<fche>
without, and with no headers, you don't have a lot to go on, yeah. it'd be weird for -us- to include openssl.h headers though. not sure how to proceed
<lindi->
fche: you mean it should be possible to implement that or is there already code that does it?
<fche>
I assume you're familiar with @cast(ptr,"type","file.h")
<fche>
lindi-, which 'it' ?
<lindi->
fche: code to parse struct definitions from object files
<fche>
that's @cast()
slowfranklin has quit [Quit: slowfranklin]
<fche>
well, more specifically, that's always been part of stap
<fche>
if you put a probe into an object file, and that object file includes debuginfo, then types of the objects in there will be visible, incl structs
<lindi->
fche: my old version was print_buffer(@cast($s, "ssl_st", "<openssl/ssl.h>")->s3->client_random, 32);
<fche>
right. and now that header has disappeared?
<fche>
heh, would be a fun example to add to our samples library
<fche>
I'd use wildcards in the process ... path names as much as possible
<lindi->
fche: I was thinking about that too
<lindi->
fche: I'd also like to know if this could be used with VMs. doesn't systemtap nowadays have some support for that as well?
<lindi->
(having the host instrument the guest)
<fche>
no recent changes; we've had 'run stap on host, target the guest' for quite some time
<fche>
stap --remote=libvirt://....
<lindi->
and it could work also for VM userland processes?
mjw has joined #systemtap
<fche>
sure should, -but- to process a stap script for the -particular- userland process versions, the host (or stap-server environment) would have to match the target guest's
<fche>
we're (ssh, don't tell anyone) working on some more systemic automation for that kind of thing
<fche>
but not done yet/soon
<lindi->
right, I need to investigate that
<fche>
so it's your job to ensure userspace in the guest matches userspace in the host or whereever
<fche>
if you'd like us to adopt a snapshot of your script into stap, that'd be cool, just post it sometimes
<fche>
sometime<no s>
<lindi->
I've been hesitating since I want to make this more reliable
<lindi->
having automated testsuite on many distros would be cool
<fche>
when you have to do distro-specific tricks (library path names / soname versions / debuginfo reliance), that may be too hard
<fche>
sometimes a script can be a template for others
<fche>
or be driven from a shell script that digs out actual distro-specific paths if required
<lindi->
in security audits it's very useful to get a global view of what's happening in some system, especially if you don't have source code
<fche>
it looks like java is kind enough to pretty-print its own secrets to stdout if you run it with -Djavax.net.debug=all
<fche>
how kind!
<lindi->
yes but you need some python to format them for tshark to read :)
<lindi->
fche: process("/usr/lib/x86_64-linux-gnu/libssl.so*") fails with "semantic error: while resolving probe point: identifier 'process' at"
<fche>
lindi-, a more complete error message / script would probably help; you may need a "?" on the probe point, to cover cases where a library does -not- actually exist