From: 'Daniel Jacobowitz' <drow@false.org>
To: Mike Stump <mrs@apple.com>
Cc: Eric Lemings <lemings@roguewave.com>,
"'gdb@sources.redhat.com'" <gdb@sources.redhat.com>,
"'gcc@gcc.gnu.org'" <gcc@gcc.gnu.org>
Subject: Re: Excluding C++ Library Code
Date: Thu, 19 Jan 2006 04:31:00 -0000 [thread overview]
Message-ID: <20060119035435.GA25699@nevyn.them.org> (raw)
In-Reply-To: <43843D96-0224-421B-BD6C-A00D455FA3B5@apple.com>
On Wed, Jan 18, 2006 at 07:25:58PM -0800, Mike Stump wrote:
> On Jan 18, 2006, at 12:22 PM, Eric Lemings wrote:
> >>Right now the infrastructure for it isn't there, but someday
> >>it will be. But how would you indicate to the debugger what
> >>constituted "uninteresting" headers?
> >
> >I figure the responsibility for this would probably reside more
> >with the compiler than the debugger (e.g. -gnostdinc++) but I
> >as hoping it could be done already.
>
> Either, we can mark the debug information with `system header', or
> gdb can strncmp ("/usr/include") and a few others... :-) gcc has a
> slightly easier time know when a header is a system header, but a
> project GUI has a easier time having check boxes for components you
> want to stop in and which ones you don't want to stop in, with system
> headers being just one of the boxes.
Right - my point was only that I've thought about it long enough to
know it needed some more thinking about :-)
I definitely agree that the debugger should be doing it, not the
compiler. It's not appreciably harder here and it makes more sense to
allow the user to just toggle a switch to suddenly step into libstdc++.
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2006-01-19 3:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-18 20:39 Eric Lemings
2006-01-19 3:54 ` Mike Stump
2006-01-19 4:31 ` 'Daniel Jacobowitz' [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-01-18 20:17 Eric Lemings
2006-01-18 20:18 ` Daniel Jacobowitz
2006-01-18 22:24 ` Dave Korn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060119035435.GA25699@nevyn.them.org \
--to=drow@false.org \
--cc=gcc@gcc.gnu.org \
--cc=gdb@sources.redhat.com \
--cc=lemings@roguewave.com \
--cc=mrs@apple.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox