|
From: Jeremy F. <je...@go...> - 2004-04-14 05:32:49
|
On Tue, 2004-04-13 at 20:09, Nicholas Nethercote wrote:
> -----------------------------------------------------------------------------
> possible new syntax
> -----------------------------------------------------------------------------
>
> Memcheck,Addrcheck:Addr4("this is the name of it")[optional part?]
> [
> fun:blahblah,
> fil:foobar,
> ..., multi-matching wildcard?
> obj:foo*,
> _, single-matching wildcard?
> obj:floo
> ]
>
> - name as string gives a clue that it's arbitrary
> - commas after trace lines indicate they're part of a sequence, as does
> grouping them together within the brackets, as does (maybe) the
> use of square brackets
> - different roles of different parts much clearer
> - ... gives more flexibility; the different meanings of "..." vs. '*'/'?'
> wildcards should be clear XXX: really?
I think _ and ... are reasonably clear as entry-matching operators,
while * and ? work within entries. It could also be useful to match
multiple entries with a |-like syntax:
fun:malloc,
fun:_myalloc_1 | fun:another_alloc | src:blah.c,
fun:common
(This suggests that we could also allow &:
fun:foobar & src:myfoo.c, // not the other foobar()
)
Also, I would prefer to avoid over-abbreviating things. Use "file:" and
"func:" rather than fil: and fun:, since they're a bit unclear. And
perhaps src: (and obj:) rather than file:, since file: is a bit generic
when we have two interesting file types.
Another nit: use {} for grouping, since that's what the languages do.
Other comments:
* Some way of enabling/disabling a suppression while keeping it in
the file and not commenting it out. This would make it a bit
easier for tools/programs to manage the file contents
* allow comments everywhere
* allow a more detailed description about the suppression, so it
can be shown in a GUI
* matching against the soname of a .so file, rather than just the
file name. The soname is canonical.
* Have a consistent quoting scheme to allow quoting anywhere
(otherwise how would we cope with someone with ',' in their
filenames - strange, but possible); also needed as symbol names
get more complex (ie, unmangled c++)
* Need to work out how to address mangling. Since there are
multiple mangling schemes, we would either need to specify which
one we want (ugly, compliler-dependent, but what we have now in
effect, only manual), or generate matching rules for all mangled
forms of the given c++ name. I guess some syntax like
"mangle:int foo(void)" would do it.
* How flexible should we be with pathname matching? Do we match
the whole pathname, or does "foo.c" mean */foo.c? i.e, should
we pay attention to whether the specified filename contains '/'
or not?
J
|