[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 foo(*a); 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. Release: GDB 5.3 Environment: any
*** 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.,: http://www.cprogramming.com/debugging/visual-studio-msvc-debugging-NoStepInto.html
> I don't have one either, but I have google. Fair enough. VS apparently also has an "only my code" option, which is presumably file-based.
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 symtab.c:search_symbols.
Created attachment 4810 [details] Patch v1 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 have here. This is my first gdb patch; please be gentle. :)
See this thread: http://sourceware.org/ml/gdb-patches/2010-06/msg00417.html
Fixed.
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. ***