fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 260 seconds]
hpt has joined #systemtap
derek0883 has joined #systemtap
derek088_ has joined #systemtap
derek0883 has quit [Ping timeout: 260 seconds]
orivej has joined #systemtap
sscox has quit [Ping timeout: 260 seconds]
lkthomas_ has left #systemtap ["Leaving"]
lkthomas has joined #systemtap
<lkthomas>
folks, I am still trying stap
<lkthomas>
stap -L 'kernel.function("*")'
<lkthomas>
I got nothing return
derek088_ has quit [Remote host closed the connection]
derek0883 has joined #systemtap
<agentzh>
lkthomas: i got a ton of output on my side.
<agentzh>
$ stap -L 'kernel.function("*")'|wc -l
<agentzh>
70907
<agentzh>
lkthomas: maybe you didn't install the kernel debuginfo?
<lkthomas>
yeah that should be the problem
derek0883 has quit [Remote host closed the connection]
<lkthomas>
actually I have a question about debuginfo, why developers always saying I have to compile debug symbols into program while linux could split debug info with the actual binary package?
<agentzh>
lkthomas: separate debug info is very common.
<agentzh>
though kernel deubginfo packages tend to include the full vmlinux file.
<agentzh>
i'm not sure about the "developers always saying" part.
<agentzh>
i'm not hearing such things myself.
<lkthomas>
I see
khaled has joined #systemtap
ema has quit [Quit: reboot]
ema has joined #systemtap
mjw has joined #systemtap
hpt has quit [Ping timeout: 260 seconds]
wcohen has quit [Remote host closed the connection]
wcohen has joined #systemtap
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 260 seconds]
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 240 seconds]
amerey has joined #systemtap
tromey has joined #systemtap
sscox has joined #systemtap
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
irker814 has joined #systemtap
<irker814>
systemtap: smakarov systemtap.git:master * release-4.3-95-gc71391b24 / buildrun.cxx runtime/linux/autoconf-kernel_read_file_from_path-offset.c runtime/transport/symbols.c: stapconf: adapt to kernel_read_file_from_path API change for v5.10-rc1
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
khaled has quit [Quit: Konversation terminated!]
khaled has joined #systemtap
khaled has quit [Remote host closed the connection]
khaled has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
<irker814>
systemtap: scox systemtap.git:scox/tls * release-4.3-80-g875469f9e / NEWS runtime/linux/stp_tls.h tapset/linux/errno.stpm tapset/linux/tls.stp testsuite/systemtap.base/tls.exp: Support tls variables on s390
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
<kerneltoast>
agentzh was telling me about stat variables
<fche>
don't trust him
<fche>
read the man page for yourself
<kerneltoast>
but i read your messages in here!
<fche>
don't trust me
<kerneltoast>
but if i can't trust you then who's flying the plane?
<fche>
interesting shift of topics ... emmmmmm
<kerneltoast>
i was wondering why you'd suggest stats variables instead of just plain atomics
<fche>
they fulfill different purposes
<kerneltoast>
agentzh was asking about a boolean var it seems
<kerneltoast>
that'd be perfect for an atomic
<kerneltoast>
as well as global numerical values... sounds like a clear atomic usecase
<fche>
stap's concurrency model is not at the individual variable access level but probe handler level
<kerneltoast>
so the stats variable will only bother with locking inter-probe access, and intra-probe access will be lock-free and barrier free? something like that?
<fche>
consider probe handlers that modify/read multiple globals
<fche>
we ensure one critical section that wraps around all access to globals, for each probe handler
<fche>
individual atomic accesses would not give the same guarantee
<fche>
at least not in the most general case
<fche>
now given that the stap translator has the entire program visible to it when translating, it could recognize special cases
<fche>
like ... "this global is the only global used in all probe handlers ... it's only read/written-to once ... so represent that one as an atomic_t"
<fche>
maybe
sscox has joined #systemtap
<kerneltoast>
hmm so the single critical section is essentially to guarantee ordering?
<fche>
well, it provides a very simple programming model
<fche>
and we like simple
<kerneltoast>
but we wanna go fasssssssst
<fche>
SORRY
<fche>
but hey
<fche>
we do have the embedded-c escape hatch
<fche>
if you know what you're doing
<fche>
use that
<fche>
heck, you could add it to our tapset library
<kerneltoast>
yeah i was thinking about either embedding c or adding a tapset for it
<kerneltoast>
atomics can get quirky really fast and it'd be difficult to provide a generic tapset library for every strange usecase
<kerneltoast>
such as the usecase in my rcu patch that got merged ;)
<fche>
starting to see why we're not exposing them :)
<kerneltoast>
they're the backbone of lockless code though
<kerneltoast>
especially in the kernel
<kerneltoast>
at least, the linux kernel
<fche>
yes, that's awesome, just not for a high level programming language that tries to be SIMPLE :)
<fche>
anyway a tapset that uses atomics in embedded-c would be definitely considered
<agentzh>
re "we ensure one critical section that wraps around all access to globals, for each probe handler", wow, that's a quite strong requirement.
<fche>
that's a strong promise, an out-held hand of friendship, to a stap script writer who doesn't want to think about such things
khaled has quit [Quit: Konversation terminated!]
<agentzh>
can we provide a FAST mode with a weaker guarentee?
<fche>
called "tapset function set xyz" :-)
<agentzh>
but it will make the scripts quickly unreadable?
<fche>
well it's not that easy e.g. considering associative arrays that need protection for metadata stuff
<agentzh>
consider that the numerical global vars are so common.
<fche>
scripts quickly unreadable? well dunno, you tell me, you can have pretty short function names, macros
<fche>
heck, kernel atomic fn names are not that short, just dupe them?