fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
thibaultcha has joined #systemtap
thibaultcha has quit [Changing host]
thibaultcha has joined #systemtap
thibaultcha has quit [Client Quit]
thibaultcha has joined #systemtap
thibaultcha has joined #systemtap
thibaultcha has quit [Changing host]
thibaultcha has quit [Client Quit]
thibaultcha has joined #systemtap
thibaultcha has quit [Changing host]
thibaultcha has joined #systemtap
thibaultcha has quit [Client Quit]
thibaultcha has joined #systemtap
thibaultcha has quit [Changing host]
thibaultcha has joined #systemtap
thibaultcha has quit [Client Quit]
thibaultcha has joined #systemtap
thibaultcha has quit [Changing host]
thibaultcha has joined #systemtap
thibaultcha has quit [Remote host closed the connection]
thibaultcha has joined #systemtap
thibaultcha has quit [Changing host]
thibaultcha has joined #systemtap
thibaultcha has quit [Quit: quit]
thibaultcha has joined #systemtap
thibaultcha has joined #systemtap
orivej has quit [Ping timeout: 260 seconds]
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
_whitelogger has joined #systemtap
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
khaled has joined #systemtap
_whitelogger has joined #systemtap
sscox has joined #systemtap
ggherdov has quit [Ping timeout: 260 seconds]
ggherdov has joined #systemtap
thibaultcha has quit [Quit: quit]
thibaultcha has joined #systemtap
thibaultcha has quit [Changing host]
thibaultcha has joined #systemtap
mjw has joined #systemtap
orivej has joined #systemtap
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #systemtap
orivej has quit [Ping timeout: 240 seconds]
wcohen has quit [Remote host closed the connection]
wcohen has joined #systemtap
orivej has joined #systemtap
amerey has joined #systemtap
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #systemtap
tromey has joined #systemtap
<modem> @define container_of(ptr, type, member) %( @cast(@ptr - @offsetof(@type, @member), @type)
<modem> %)
<modem> i added that in my script
derek0883 has joined #systemtap
<modem> semantic error: unresolved function (similar: error, log, HZ, assert, bio_op): identifier 'container_of' at 8897c1b1a1795cab23d5ac13e4e23bf0b5f4e0c6.stp:73:10 source: inode = container_of ($head, "inode", "i_rcu");
<modem> nevertheless I keep having issue in my script
<modem> any advices on how to properly use container_of ? Thanks
<modem> Systemtap translator/driver (version 4.0/0.176, Debian version 4.0-1)
<modem> maybe that's my issue
<modem> let's upgrade to latest, sorry for buzzing
<fche> @container_of is how you refer to macros
<modem> hah
<fche> you might need @module_container_of if the @cast needs a module
<modem> semantic error: 'struct inode' (./include/linux/fs.h:593) is being accessed instead of a member such as '->__i_nlink': operator '@cast'
<modem> does it want to force me using a dereference instead of assigning a variabe with type casted ?
<fche> what's the complete script?
<modem> inode = @container_of (register("rdi"), "inode", i_rcu);
<modem> only that
<modem> struggling from a struct rcu_head *head in some rcu_callback
<fche> could you fpaste the more complete script so I can try it here?
<modem> sure, thanks!
derek0883 has quit [Remote host closed the connection]
<modem> thanks you1
<modem> thanks you!
derek0883 has joined #systemtap
<modem> note register("rdi") is supposed to be $head but I tried that because it wasn't working
derek0883 has quit [Ping timeout: 260 seconds]
<modem> ok got it working! Thanks
<fche> great
<modem> i missed &
<modem> inode = &@container_of ($head, "inode", i_rcu);
<modem> tysm
<fche> ah yes
modem has quit [Ping timeout: 272 seconds]
modem has joined #systemtap
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 260 seconds]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
mjw has quit [Quit: Leaving]
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 260 seconds]
derek0883 has joined #systemtap
thibaultcha has quit [Quit: quit]
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
thibaultcha has joined #systemtap
thibaultcha is now known as Guest24628
Guest24628 has quit [Client Quit]
thibaultcha has joined #systemtap
thibaultcha is now known as Guest40076
sscox has quit [Ping timeout: 240 seconds]
tromey has quit [Quit: ERC (IRC client for Emacs 27.1.50)]
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 240 seconds]
Guest40076 has quit [Quit: quit]
thibaultcha has joined #systemtap
thibaultcha is now known as Guest96422
derek0883 has joined #systemtap
Guest96422 has quit [Quit: quit]
<modem> fche:
thibaultcha has joined #systemtap
thibaultcha is now known as Guest87320
sscox has joined #systemtap
amerey has quit [Ping timeout: 240 seconds]
<modem> i think i have a problem with an .return probe
<modem> apparently the subroutine (main routine) has not been executed when the .return probe run
<modem> I tried probing one function above in the calling hierarchy
<modem> and it still hasn't run my main routine
<modem> i looked at the assembly and it seems it's triggered from running return probe in function returning void
<modem> the last opcode is a jmp to the subroutine
<modem> i guess that systemtap is adding its int3 on the last instruction
<modem> hence the return probe run before the last instruction has been executed
<modem> in my case before the main subroutine has been executed
<modem> no no no my bad
<modem> that's not my issue
<modem> i have been badly testing per-cpu variable
<modem> i suspect the probe handler might run on another cpu