18:40 <irker560> systemtap: dsmith systemtap.git:refs/heads/master * release-3.0-18-g67533af / tapset/linux/syscalls2.stp testsuite/systemtap.syscall/preadv.c testsuite/systemtap.syscall/pwritev.c: Improve 64-bit file offset handling in syscall.preadv and syscall.pwritev. http://tinyurl.com/gv5zzmf

18:59 <irker560> systemtap: dsmith systemtap.git:refs/heads/master * release-3.0-19-g67004c5 / tapset/linux/aux_syscalls.stp tapset/linux/nd_syscalls2.stp tapset/linux/syscalls2.stp testsuite/systemtap.syscall/preadv.c testsuite/systemtap.syscall/pwritev.c: Fix PR19905 by adding support for the preadv2/pwritev2 syscalls. http://tinyurl.com/zxfoujj

19:59 <litb> hello all

19:59 <litb> is it possible to print std::string, std::vector and friends with systemtap?

19:59 <litb> i.e instead of printing the aggregation structure, print the actual payload?

20:00 <fche> we could use some library functions for that - kind of like the python pretty-printers gdb uses

20:01 <fche> jistone, hm... maybe we could use overloaded functions in the runtime for prettyprinting funky types

20:01 <fche> function prettyprint:string(ptr,type_string) { if (type_string=="std::string....") { .. } else { next } } ??

20:02 <fche> and have the $$ expansion call into those?

20:02 <jistone> why do it at runtime (overloaded function) when that type_string is statically known?

20:03 <jistone> (also, fwiw, it will likely be "std::basic_string<blah blah blah>")

20:03 <fche> (that's an optimization!)

20:04 <fche> ie. avoid hard-coding it within the translator

20:04 <fche> instead let the tapset - expandable! - handle it

20:04 <fche> that could be an avenue for hooking in foreign-language values too

20:05 <jistone> (feels like you're dismissing an architectural question as optimization out of hand)

20:05 <fche> I agree as much should be compile-time as possible

20:06 <fche> and I also think as much should be expandable (not elaborate.cxx c++) as possible

20:06 <jistone> the pretty-printer has to know the type to pass around .. how extensible can this really be?

20:06 <fche> the $$ expansion code in the translator could call the pretty-printer function with the type name string

20:06 <fche> ie make that part of the 'abi' so to speak

20:07 <fche> and as for static compilation ...

20:07 <jistone> right, but if you know the type name string, you already have info about the language

20:07 <fche> but the translator would need to know nothing but the type name (out of dwarf)

20:07 <fche> and re static compilation, just to finish the thought ...

20:08 <litb> can i write such a function today with custom .stp files?

20:08 <jistone> -> stap pass-2 plugins?

20:08 <fche> an optimization pass that 'de-virtualizes' or de-overloads various alternative functions based upon a pattern of usage (look for PARAM2 ~= REGEX e.g.) and evaluate it at compile time ... bob's your uncle

20:08 <litb> i could write a "mapping" c struct and @cast the std::string pointer to it, as long as the c struct has the same memory layout. then i could walk along the pointers to reach the stored char[]

20:09 <jistone> litb, if you know you have a std::string in hand, you could print however you like. there's just no way to hook into pretty-printing as fche is suggesting

20:09 <litb> for the case that the library has no complete debug information

20:09 <fche> litb, you can do so today, sort of: $str->_m->buf$ or somesuch

20:09 <litb> jistone: ah i see. is the "mapping" c struct a good idea?

20:09 <litb> if we have no debug information, like with libQtCore*.so ?

20:10 <fche> where is your probe ? how are you getting hold of a context data value?

20:10 <litb> it's a QString i'm actually worrying about, which has this stupid d pointer whose pointee type is only defined in the qstring.cpp file

20:11 <fche> dwarf needs the declaration rather than definition of the type (to be pedantic); so the caller binary may well have enough

20:11 <fche> if it's not an opaque type

20:11 <litb> fche: i'm planning to write .function("foo") probes and access the parameters using $bar

20:11 <fche> yes what.function though? library or your binary ?

20:11 <fche> as in which "what." ?

20:11 <litb> fche: well the type is only forward declared like class QStringPrivate; or something

20:12 <litb> and my system's libQtCore*so has no debug information to account for the missing fields information

20:12 <jistone> if you can get to headers, @cast($foo, "QStringPrivate", "<qstring-impl.h>")

20:12 <litb> fche: ah. probe process("firmwarebinary").function

20:12 <litb> jistone: it's c++ code :/

20:12 <jistone> but I think @cast only expects c-headers at the moment

20:13 <jistone> right

20:13 <litb> i was in the impression that this only works for c

20:13 <litb> so I thought perhaps i could hand-craft a C struct whose memory layout is compatible

20:13 <jistone> not impossible to imagine though, I think there may even be a bug filed...

20:13 <litb> and cast it to that

20:13 <fche> litb, yeah. or call out to an embedded-c function of your own that Knows All

20:13 <fche> (all else failing)

20:14 <litb> ah can i actually call functions out of an stp file that is defined in the traced binary?

20:14 <litb> that would be simplest

20:14 <fche> nope, embedded-C in the .stp file

20:14 <fche> calling out to userspace, no go

20:14 <fche> (apprx.)

20:15 <litb> ah i see now, i can write C code in there and have my little dirty struct right there

20:16 <jistone> fwiw, I don't see a bug, but make_typequery_umod() is the place that assumes C headers, in case someone wants to enhance this...

20:16 <fche> pls file a bug so we don't forget

20:16 <litb> wouldn't it need to compile a kernel module as c++ code then?

20:16 <litb> i didn'T think that's possible

20:17 <fche> nope, it's just trial-compiling the user-given header file with userspace compiler, to extract dwarf info

20:17 <jistone> no, this just compiles a dummy object for us to read debuginfo from

20:17 <fche> that too!

20:17 <litb> ah i see, clever

20:17 <fche> jistone invented it

20:43 <jistone> https://sourceware.org/bugzilla/show_bug.cgi?id=19930

20:44 <fche> thanks

20:49 <litb> jistone: ah so if i'm doing remote (ssh) userspace stap, and the remote machine runs non-debug binaries, and my local dev machine has the debug binary with the symbols and field names, I can use that binary with @cast ?

20:50 <litb> i imagine i could then also compile my own qt with debug symbols, and without relinking existing qt apps (they still use the release version), i could access QString objects

20:51 <jistone> yes to all, but you need to be careful that you've really matched ABI

20:54 <litb> i see

21:09 <litb> jistone: does it have to compile for the compiler to generate the DWARF? or can it cause an error and it still can generate the dwarf info?

21:10 <litb> i imagine, that generating the dwarf info is much simplier than generating a fully working object file, so I wonder whether a debuginfo-only compile suffices and whether it's possible

21:16 <jistone> litb, for this we only care about debuginfo type layout, not any object code. but I don't know any way to compiler *just* that debuginfo

21:16 <jistone> (there are tools to strip debuginfo into separate files, but I think that's different than what you're asking)