Unless you know the names of the markers put into a binary it is hard to place any probes because currently trying to list the markers with stap -l will return the translated process("bla").statement(123456789) probe points, which don't tell you much about what exactly will be probed. Likewise stap -L should print argument names (and types) if possible.
This works fine, modulo one gets a line number instead of a label name, for gcc where there are DW_TAG_label that can be queried: stap -c ./static_uprobes.x -l 'process("static_uprobes.x").mark("*")' process("static_uprobes.x").function("bar@static_uprobes.c:11") process("static_uprobes.x").function("baz@static_uprobes.c:17") process("static_uprobes.x").function("baz@static_uprobes.c:20") process("static_uprobes.x").function("buz@static_uprobes.c:28") gcc compiled probes all use .label now. This is a tough one for g++ 4.3.2 because there are usually no DW_TAG_label to query so everything is done by converting info in .probe to .statement, therefore there is no obvious way to hook into the -l machinery.
Thanks for looking into this Stan. I finally get the idea now. So I think we actually have two issues (maybe open a two separate bug reports for them). First in case of having only statement probes available to translate the mark() probes we cannot easily list all the statement() probes for them. Secondly by translating the mark() probes to either function() or statement() probes and having -l list these translated probes the user doesn't really get a list of available mark() probe names (so they won't actually know which mark("*) probe gc-begin, transaction-end, etc) corresponds to which or actually which ones are available by running -l (but maybe that isn't the purpose of -l and we need some other mechanism for that?)
commit: 3c1f71d54d * tapsets.cxx (dwflpp::build): Use .label for listing mode.
This broke again with the switch to always using the .probes section.
commit: c5746f91b1 Customize .mark -l output.