|
From: Nicholas N. <nj...@ca...> - 2004-04-14 14:43:38
|
On Wed, 14 Apr 2004, Jeremy Fitzhardinge wrote:
> I think _ and ... are reasonably clear as entry-matching operators,
Unfortunately, if you don't look at the manual, you won't know what they
are from context (unlike * and ? which people will likely be able to
guess... not that anyone ever uses ?). Maybe that's unavoidable.
> 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()
> )
I'm wary about these -- have you seen particular cases where these would
be useful, or are you just hypothesizing? All the things I've mentioned
have come from user feedback, people saying either "I want to be able to
do this", or being confused about something. No point adding complexity
if no-one will use it.
> 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.
Sure.
> Another nit: use {} for grouping, since that's what the languages do.
I specifically didn't choose {} because it's used to groups statements in
procedural languages, which is not at all like a call trace. I
deliberately used [] because it's often used as list notation (eg. in
Haskell, Prolog), and a call trace can be considered exactly as a list.
> 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
ok, any ideas how?
> * allow comments everywhere
yes
> * allow a more detailed description about the suppression, so it
> can be shown in a GUI
can you give an example?
> * matching against the soname of a .so file, rather than just the
> file name. The soname is canonical.
I don't understand what you mean by canonical here...
> * 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++)
hmm, yes
> * 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.
I'm tempted to stick with the current system.
> * 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?
I think current system -- exact matches against entire paths -- seems ok.
N
|