Bug 8287

Summary:	skipping boring functions when stepping
Product:	gdb	Reporter:	David Carlton <carlton>
Component:	cli	Assignee:	Justin Lebar <justin.lebar>
Status:	RESOLVED FIXED
Severity:	enhancement	CC:	cam, esp5, f18m_cpp217828, gdb-prs, justin.lebar, richardg.work, tromey
Priority:	P3
Version:	5.3
Target Milestone:	7.4
Host:		Target:
Build:		Last reconfirmed:
Bug Depends on:	11614
Bug Blocks:
Attachments:	Patch v1

Description David Carlton 2003-04-18 22:28:00 UTC

[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

Comment 1 Tom Tromey 2010-02-11 17:54:25 UTC

*** Bug 8661 has been marked as a duplicate of this bug. ***

Comment 2 Tom Tromey 2010-02-11 17:54:34 UTC

*** Bug 11117 has been marked as a duplicate of this bug. ***

Comment 3 Justin Lebar 2010-02-11 19:16:27 UTC

(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.

Comment 4 dje 2010-02-23 18:29:28 UTC

Or maybe provide a way to step into function calls, bypassing any function calls
that set up arguments.  I've called this "fstep".

Comment 5 Justin Lebar 2010-05-01 08:21:55 UTC

I'm working on a patch for this.

Comment 6 Justin Lebar 2010-05-06 17:45:45 UTC

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.

Comment 7 Pedro Alves 2010-05-06 18:02:28 UTC

Did you take a look at how other debuggers implement this?  E.g., the
ubiquitous Visual Studio uses flexible regexps, as the OP suggested.

Comment 8 Pedro Alves 2010-05-06 18:06:52 UTC

IMO, this should be a separate list from breakpoints.

Comment 9 Justin Lebar 2010-05-06 18:26:01 UTC

(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?

Comment 10 Pedro Alves 2010-05-06 18:34:09 UTC

I don't have one either, but I have google.  E.g.,:
http://www.cprogramming.com/debugging/visual-studio-msvc-debugging-NoStepInto.html

Comment 11 Justin Lebar 2010-05-06 19:23:41 UTC

> 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.

Comment 12 Justin Lebar 2010-05-07 04:35:07 UTC

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?

Comment 13 Pedro Alves 2010-05-07 19:00:17 UTC

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 :-) ).

Comment 14 Pedro Alves 2010-05-07 19:24:14 UTC

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.

Comment 15 Justin Lebar 2010-05-22 20:58:02 UTC

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.  :)

Comment 16 Tom Tromey 2011-10-05 15:19:58 UTC

See this thread:
http://sourceware.org/ml/gdb-patches/2010-06/msg00417.html

Comment 17 Tom Tromey 2011-11-08 17:12:25 UTC

Fixed.

Comment 18 Richard Geary 2013-08-04 20:42:31 UTC

For the benefit of future users, this is now called "skip" not "blacklist". To use this feature, see "help skip".

Comment 19 Pedro Alves 2016-02-05 14:00:59 UTC

*** Bug 9650 has been marked as a duplicate of this bug. ***