18:04 <agentzh> fche: are you okay with adding new stap options -Wno-unused-variable and -Wno-unused-function to suppress those "Eliding unused ..." warnings?

18:56 <agentzh> or maybe just -Wunused ?

18:57 <agentzh> sorry, should be -Wno-unused

19:03 <agentzh> for auto-generated stap scripts, such warnings are just too many...

19:03 <agentzh> so it would be great to have a way to silence them all.

19:04 <agentzh> similarly, we could also have the -Wno-side-effect-free option to silence those "side-effect-free expression" and "side-effect-free function" warnings from the stap translator?

21:09 <fche> agentzh, is -W too blunt for your purposes?

21:09 <fche> are there any warnings you want to see for your generator's output ?

22:42 <agentzh> fche: those warnings are usually helpful when developing the tools. but for production use, we do not want to see them again.

22:42 <fche> ok I meant what about "stap -w" ?

22:43 <agentzh> what does it do?

22:43 <fche> -w Suppressed warnings mode. Disables all warning messages.

22:43 <agentzh> oh, i see, it's already there.

22:43 <agentzh> yeah, too overkill for our purposes.

22:44 <fche> so the question is what warnings are included in that which you need to see

22:44 <agentzh> yeah, just like the granularity control in gcc, for example.

22:44 <agentzh> gcc also has -Wno-unused-function and -Wno-unused-variable, in addition to -Wno-unused. i won't mind if we can have them all :)

22:45 <agentzh> stap does not have -Wunused-parameter, does it? ;)

22:45 <fche> no, just plain -w

22:46 <agentzh> i mean warnings for unused function parameters.

22:46 <fche> not sure

22:46 <agentzh> never seen it myself anyway :)

22:47 <fche> anyway, if you're sure you need a more cosmetic warning suppression option, I can suggest something that's not a pandora's box of future options

22:47 <agentzh> for example?

22:47 <agentzh> any suggestions?

22:47 <agentzh> you are not happy with gcc's option names?

22:48 <fche> a -w-suppress SUBSTRING or REGEX wherein systemtap_session::print_warning can match against the incoming message_str and filter based on a set of matches

22:48 <agentzh> i would go for -Wno-xxx to be consistent with gcc's CLI, but i understand it does not have to be the same as gcc.

22:48 <fche> i.e., not to overcomplicate the command line option parsing machinery

22:49 <agentzh> ah, that's quite flexible.

22:49 <agentzh> SUBSTRING should be good enough.

22:49 <agentzh> REGEX is a bit overkill for this purpose.

22:49 <fche> yeah probably

22:50 <agentzh> okay, we'll go this way then.

22:50 <fche> one downside is i18n stuff ... ::print_warning gets the translated form of messages methinks

22:50 <agentzh> it sounds easier to implement with extra flexibility.

22:50 <fche> but as long as you're using in a single language environment, that should be okay

22:50 <agentzh> oh, the i18n stuff.

22:50 <agentzh> i think we could only match against the msg id, which is English?

22:51 <fche> ::print_warning doesn't see a message 'id', it sees a string

22:51 <agentzh> alas. a bit too late in timing.

22:55 <fche> but maybe good enough for your development-time purposes

22:59 <agentzh> yeah, good enough even for production use.

22:59 <agentzh> we could always enforce LC_ALL=C anyway.

22:59 <fche> or for production production, use -w

22:59 <agentzh> as long as you are okay with that.

23:00 <agentzh> we do not want to filter out all warnings in production either. just those we know about.

23:01 <agentzh> we'll work on a patch for --w-suppress then.

23:01 <agentzh> is it --w-suppress or -w-suppress ?

23:02 <agentzh> double dashes look better to me.

23:02 <fche> yeah, or --no-w SUBSTRING

23:02 <fche> think of something tasteful, it's easy to tweak during review anyway

23:02 <agentzh> i like --no-w more :)

23:02 <agentzh> less typing. yay

23:02 <fche> heh, put it into your $HOME/.systemtap/rc, and never have to type it again

23:03 <agentzh> well, still need to tune it on a case by case basis :)

23:03 <agentzh> especially when hacking on stap itself.

23:07 <agentzh> fche: we are already working on the floating-point number support in stap.

23:07 <agentzh> the current plan is to use long to store a double.

23:07 <agentzh> and use NaN tagging to store a float.

23:07 <agentzh> not ideal for 32-bit kernels though but the changes would be minimal to get this working on 64-bit kernels.

23:08 <agentzh> ideally we should introduce native float and double types in both the type system and the kernel-space runtime, but that would be a huge change.

23:09 <agentzh> we'd rather keep the changeset minimal at this point.

23:10 <agentzh> stap definitely needs more fine-grained integer types too :)

23:11 <agentzh> a single long type really sucks and we have to accommondate that in our higher level language compiler.

23:11 <fche> maybe ... simplicity has been attractive

23:11 <fche> anyway, as with any other serious change, would love to see a problem statement, examples, an outline of the solution, that kind of thing

23:11 <agentzh> sure.

23:13 <agentzh> the thing is that it's often the case that the target process is written in C/C++ and to traverse the data structure in the target process, one usually has to port existing traversal code in the target C/C++ program over to stap. and the type system mismatch creates too many pitfalls that are so difficult to get exactly right.

23:14 <agentzh> that's one of the motivatins of our c2stap compiler. another motivation is to avoid writing tools for multiple different debugging platforms over and over again (like stap, gdb, lldb, bcc, and etc).

23:16 <agentzh> we've been pushing the limit of stap in our own uses of stap.

23:17 <agentzh> gdb python succeeds in that it keeps the full type system and their aritmetic rules at runtime though one still has to take care of C's own implicit type conversion rules himself (like integer promotion and etc).

23:17 <fche> I must say your c2stap effort feels quixotic -- but am happy to consider related stap improvements that don't undermine its overall feel or security.

23:18 <agentzh> fche: well, that's just automating what we've been doing manually for years.

23:19 <agentzh> and the stap backend of our compiler has already been passing most of the tests in our test suite (the gdb py backend has passed them all).

23:20 <agentzh> so it's not that quixotic as it sounds :)

23:20 <fche> wild

23:21 <agentzh> after hacking floating-point numbers, variable-aware usymdata() tapset function, and non-null-terminated string types into stap, our ylang compiler's stap backend can pass all of the tests.

23:21 <agentzh> after that, we'll work on a dwarf-less stap backend for our ylang compiler.

23:22 <agentzh> and then the bcc backend or just help improving stap's bpf runtime instead. not decided yet.

23:23 <agentzh> both bcc and stap's bpf runtime look primitive and immature.

23:38 <fche> kernel bpf is kind of primitive (by design)

23:42 <agentzh> *nod*

23:42 <agentzh> so we're considering a custom bpf runtime as a custom kernel C module.

23:43 <fche> and getting that integrated into the kernel proper?

23:43 <agentzh> not holding my breathe for that.

23:43 <agentzh> you do know those kernel folks ;)

23:44 <agentzh> it can be much more political and subjective than technical.

23:44 <fche> so I hear :)

23:44 <fche> but OTOH if merging it upstream is not on the table, then why bother? as opposed to compiling straight to c a la systemtap classic?

23:45 <agentzh> well, we could give it a shot :)

23:45 <agentzh> just not be hopeful.

23:46 <agentzh> we might also port it over to other operating systems as well.

23:46 <agentzh> just play as we go :)

23:48 <agentzh> fche: btw, i do not believe in a single unified debugging framework. i believe in targeting different debugging toolchains as we see fit. the latter is much more practical. for example, stap cannot be used to debug core dump files (yet), nor can it be used on other operating systems without virtualing a linux.'

23:48 <agentzh> *virtualizing

23:49 <agentzh> so abstraction can be really powerful here.

23:50 <agentzh> our ylang is such an abstraction.

23:51 <agentzh> it is also not just a single language (a superset of C). we're planning to add more language frontents to it atop the existing C frontend. for example, we can use python when debugging python apps, use lua for lua apps, php for php apps, and etc.

23:51 <agentzh> the possibilities are unlimited.

23:52 <agentzh> just build up the abstractions and let optimizing compilers emit fast debugging tool code.

23:53 <agentzh> stap is great in that it has multiple backens (kernel, dyninst, bpf), but the frontend is a bit too limited.

23:53 <agentzh> but i do understand of being minimalistic and simplistic.

23:53 <agentzh> *do understand the intention of

23:53 <fche> it's for humans to write code in, not compilers

23:54 <agentzh> so in our ylang compiler, stap is just a vm and a backend :)

23:54 <fche> have you published anything about ylang?

23:54 <agentzh> humans already write much code, and for debugging, we just move the existing C code (or other languages' code) over :)

23:54 <agentzh> instead of writing it from scratch again.

23:55 <agentzh> re published anything about ylang: not yet.

23:55 <fche> ok

23:56 <agentzh> the target programs already know how to digest and traverse their own data structures.

23:56 <agentzh> so it's wasteful if we have to redo that for stap/gdb/etc tools.

23:56 <agentzh> and risk introducing bugs in our own stap/gdb py code.

23:57 <agentzh> not to mention the burden of maintaining the code as the target programs evolve.

23:59 <agentzh> it looks very natural to simply reuse what we already have :)