[Converted from Gnats 1182]
(A user at Kealia suggested this to me, and I've found this
to be annoying in my own debugging, too.)
It might be nice to be able to ignore certain 'boring'
functions when stepping: to tell 'step' (or another
command like step) that it should step into the next
function on the current line (if any) that isn't on some
list of excluded functions. This would be really useful
when debugging C++ code: in an expression like
it happens all the time that a is really a smart pointer,
not a raw pointer, so you first step into the smart
pointer's operator*, then have to type 'finish', then have
to type 'step' again.
Any possible design would have to be somewhat flexible
to handle this case: smart pointers are template classes,
so this should be able to handle methods of template
classes without requiring the user to specify the types
of every single possible instantiation. So I guess
this hypothetical ignore list should be a list of
regexps instead of just a list of names to match exactly.
*** Bug 8661 has been marked as a duplicate of this bug. ***
*** Bug 11117 has been marked as a duplicate of this bug. ***
(In reply to comment #0)
> So I guess
> this hypothetical ignore list should be a list of
> regexps instead of just a list of names to match exactly.
It might be simpler to specify that gdb should step through all functions in a
given file, although that's obviously inflexible.
Or maybe provide a way to step into function calls, bypassing any function calls
that set up arguments. I've called this "fstep".
I'm working on a patch for this.
I have a patch which lets you blacklist files and functions. GDB won't step
into a blacklisted file or function.
I'd like some advice on the UI for this, though, so I don't have to write it twice.
In particular, the blacklist is a lot like the list of breakpoints. You want to
do to blacklist entries basically everything you can do to breakpoints: list,
enable, disable, delete. This suggests that blacklist entries should perhaps be
a type of breakpoint.
On the other hand, a blacklist entry is exactly the opposite of a breakpoint. A
breakpoint/watchpoint/tracepoint says "I'm interested in this", but a blacklist
entry means "I want to ignore this". This suggests that we should keep the
blacklist separate from the list of breakpoints.
I'm leaning towards making the blacklist separate from the breakpoint list, but
I'm happy to do it either way.
Did you take a look at how other debuggers implement this? E.g., the
ubiquitous Visual Studio uses flexible regexps, as the OP suggested.
IMO, this should be a separate list from breakpoints.
(In reply to comment #7)
> Did you take a look at how other debuggers implement this? E.g., the
> ubiquitous Visual Studio uses flexible regexps, as the OP suggested.
I don't have a copy of VS in front of me right now; do you know if it lets you
blacklist a whole file?
I don't have one either, but I have google. E.g.,:
> I don't have one either, but I have google.
Fair enough. VS apparently also has an "only my code" option, which is
Also, I'm not convinced that full-on regexps are necessary. Matching either a
string or a string followed by any sequence of characters (i.e. allowing 'foo'
and 'foo*' but not 'foo*bar' as blacklist function filters) would work for
templates. Is there any other reason to have something more complicated here?
To filter on a specific template instantiation type, namespaces, be able to
filter function overloads, etc. Why design something that is limited upfront,
when it's pretty much guaranteed users will want more flexibility?
I'm not convinced that regexps necessarily complicates the
implementation. We have other regexp uses in gdb already.
Also, I think we should be able to filter a whole directory,
in addition to individual files. It doesn't have to be implemented in
the first patch, of course, may it should be kept in mind not to make
it impossible to extend in the direction.
Visual Studio's implementation seems quite nice, in that it allows
a NoStepInto and StepInto override each other depending on priority
(or position in list). Sort of feels like a ClearCase config spec
(not that I like ClearCase, mind you :-) ).
I think you'd be able to extract/abstract any necessary bits from
the "rbreak" implementation. See symtab.c:rbreak_command, and
Created attachment 4810 [details]
This patch has a few minor outstanding details, marked with TODOs in the code.
In particular, the breakpoint code has some special-casing for Objective-C that
I don't understand but I may want to emulate in this patch, and there are two
error conditions that I'm not sure how to exercise with a testcase. Any input
on these issues would be appreciated.
I don't handle blacklisting files or functions using regular expressions in
this patch, but I'd be happy to work on that after we're satisfied with what I
This is my first gdb patch; please be gentle. :)
See this thread:
For the benefit of future users, this is now called "skip" not "blacklist". To use this feature, see "help skip".
*** Bug 9650 has been marked as a duplicate of this bug. ***