fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
sscox has quit [Quit: sscox]
sscox has joined #systemtap
sscox has quit [Client Quit]
sscox has joined #systemtap
khaled has quit [Quit: Konversation terminated!]
amerey has quit [Quit: Leaving]
hpt has joined #systemtap
orivej has quit [Ping timeout: 252 seconds]
fdalleau_away is now known as fdalleau
orivej has joined #systemtap
orivej has quit [Ping timeout: 252 seconds]
khaled has joined #systemtap
mjw has joined #systemtap
dxu has quit [Quit: Bridge terminating on SIGTERM]
dxu has joined #systemtap
hpt has quit [Ping timeout: 252 seconds]
tromey has joined #systemtap
irker083 has joined #systemtap
<irker083>
systemtap: wcohen systemtap.git:master * release-4.4-140-g8b74817e5 / tapset/linux/dev.stp: Adjust tapset dev.stp to get partition number from newer block_device struct
amerey has joined #systemtap
orivej has joined #systemtap
orivej has quit [Ping timeout: 240 seconds]
khaled has quit [Quit: Konversation terminated!]
khaled has joined #systemtap
khaled has quit [Quit: Konversation terminated!]
khaled has joined #systemtap
<irker083>
systemtap: wcohen systemtap.git:master * release-4.4-141-gae2cc8164 / tapset/linux/ucontext.stp: Correct ucontext.stp umodname function call to _stp_umod_lookup
<kerneltoast>
fche, bonjour
<fche>
so far so good
orivej has joined #systemtap
<kerneltoast>
o noice
<kerneltoast>
i was gonna ask what you'd think about adding user process breakpoints to stap
<kerneltoast>
like kernel.data(addr) but for a process
<fche>
kerneltoast, if the kernel were to provide such a facility, we'd gladly exploit it
<kerneltoast>
register_user_hw_breakpoint() seems like it
tromey has quit [Quit: ERC (IRC client for Emacs 27.1)]
<fche>
well the slacker hasn't found someone to IMPLEMENT the idea yet tho
<kerneltoast>
unbelievable
<kerneltoast>
but he's a visionary, no doubt
<fche>
doubt
<agentzh>
oh, didn't know there is even a PR for it :D
<agentzh>
we need it to track down a very mysterious bug.
<agentzh>
a global variable can be randomly changed without leaving any trace.
<agentzh>
if we can watch on that C variable's memory address, and then print out a C backtrace once it is changed, the problem will be solved immediately.
<fche>
aha, like a gdb watchpoint
<agentzh>
indeed
<kerneltoast>
fche, got any protips for implementing this? I've never played with breakpoints aside from debugging my friends' code in gdb in college
<fche>
I'd probably look at the implementation of kernel.data() in stap
<kerneltoast>
can it all just be copied?
<fche>
and adapt it to this other api, and of course call the probe process.data()
<fche>
all just be copied? of course not :) but it's a starting point
<kerneltoast>
err i mean
<fche>
it depends on how close the kernel api is to the user api
<kerneltoast>
ah
<fche>
kernel-hwbkpt to user-hwbkpt
<fche>
process.data("symbol") might be a nice user interface for it, if $symbol is resolvable as a global var
<agentzh>
fwiw, we only need the hex address, but i agree symbol name is a nice to have for general users.
<agentzh>
it can be done in separate patches?
<agentzh>
we hope to get this done asap.
<agentzh>
if symbol name won't take too long.
<agentzh>
for symbol, we need a module name as well?
<agentzh>
and for hex address too since it's relative address anyway.
<agentzh>
like process.data("symbol", "module")
<agentzh>
or process.data(0xHEX, "module")
<agentzh>
for our own use cases, we only need the latter form.
<agentzh>
but the first form is handy for debugging and etc as well.
<agentzh>
we may need to invoke the vma tracker in the implementation i guess.
<agentzh>
like @cast() or @vma().
<agentzh>
or @var()
<agentzh>
kerneltoast: please make sure we can also use @var() and user_long_string() and etc in that probe handler context.
<agentzh>
and print_ubacktrace()
<agentzh>
it should be the process context.
<agentzh>
so pid() should work too.
<agentzh>
not sure if ebpf supports such things. we may not worry about ebpf runtime for this work for now :)
<agentzh>
and neither should we worry about dyninst.
<agentzh>
at least for now.
* kerneltoast
breathes a sigh of relief about the lack of ebpf
<agentzh>
lol
<fche>
hex address is fine
<fche>
I mean I wouldn't mandate someone build two functions when they're only interested in one, and it's useful already
<fche>
you're not on my payroll :)
<kerneltoast>
but i thought the whole point of oss was to demand free featurez
<fche>
use of @var() etc. should be OK if the kernel api for user data breakpoints gives one a pt_regs
<kerneltoast>
there's a lotta c++ code for kernel.data()...
<fche>
sell it by the pound
<kerneltoast>
good news is that the api looks the same, just need to give a task struct pointer for user breakpoints
<kerneltoast>
but i'm very lost on where to start churning out a process.data() api
<kerneltoast>
fche, think you could just like set up the functions for me in the c++ code
<kerneltoast>
and then i could fill out the meat
<kerneltoast>
just empty functions needed for process.data()
<agentzh>
kerneltoast: i think you can borrow the boilerplate C++ code from process.statement(0xHEX)?
<agentzh>
oh, sorry, the module arg is not needed.
<agentzh>
should be process("module").data(0xHEX) instead.
<agentzh>
it should be similar to process("module").statement(0xHEX) or process("module").function("symbol")
<agentzh>
the latter two are already there.
<kerneltoast>
now to find where that code is...
<fche>
the .statement() -builder- bits go down the road of dwarf, which you do not want
<fche>
the part that's useful there is the way the task_finder* goo is set up to identify the target processes
<agentzh>
oh yeah we don't need to verify if the 0xHEX address is on the instruction boundary.
<agentzh>
since it's the data address anyway.
<fche>
well not just that, all the other dwarf stuff that .statement / .function probes do, you don't want to even go near
<agentzh>
right
<kerneltoast>
fche, is the `s.pattern_root->bind(TOK_KERNEL)->bind_num(TOK_HWBKPT)` stuff the entry point for parsing kernel.data()?
<fche>
that's the part that registered the probe point family in the tree used for resolving probe point types
<fche>
but yeah start looking around there
<fche>
the 'builder' object is responsible for taking the probe point object (that matches all the pattern bindings), and turn it into a SOMETHING_derived_probe_point
<kerneltoast>
so i can just slap in a TOK_PROCESS thingy and all of a sudden process.data() will get resolved?
<fche>
it will get -dispatched- to your builder object
<fche>
resolving ... as in mapping the probe point parameters to something operational - that's the builder's job
<kerneltoast>
ah
<kerneltoast>
how do we introduce process.data() to the parser
<fche>
that's exactly this pattern_root->bind() doohickey
<kerneltoast>
oh cool so nothing deeper than that for just making the parser aware of this
<fche>
right
<fche>
(not the parser per se but an early step of pass 2 elaboration)\
<kerneltoast>
what's the difference between bind_num and bind_str?
<fche>
whether the probe point part takes a number or a string parameter
<fche>
so in your case probably bind_num("data") so your builder gets a literal number for address