From: Jim Ingham <jingham@apple.com>
To: Andrew Cagney <ac131313@ges.redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC] breakpoints and function prologues...
Date: Sat, 24 Aug 2002 18:31:00 -0000 [thread overview]
Message-ID: <30A3EC98-B7A5-11D6-BB10-000A277A8808@apple.com> (raw)
In-Reply-To: <3D667F89.8090603@ges.redhat.com>
Yes, we could change -break-insert to do this.
It would still break when somebody uses the console to set breakpoints
from within Project Builder, however. Like with Insight, we try to
support the console as well as we can from PB (we don't do as good a
job as Insight, but we are working towards it).
I guess we could go note the breakpoint set event, delete the
breakpoint that was just set IF it was set with file:line, and reset it
with the "move me past the prologue" cookie. But this seems a bit of a
hack.
The other option is to add a "set make-old-gdb-users-unhappy-with-break
{on,off}" command, and set that from the IDE when we start up gdb. I'm
not real thrilled about this either...
Jim
On Friday, August 23, 2002, at 11:31 AM, Andrew Cagney wrote:
>> On Thursday, August 22, 2002, at 04:34 PM,
>> gdb-patches-digest-help@sources.redhat.com wrote:
>>> The question is, is there a strong reason to change a behavior
>>> that has been consistent for a very long time (even if undocumented).
>>> Even if the ability to debug the prologue is un-important for most
>>> users, it is important to some, and those users (GCC developers,
>>> for instance) may be quite accustomed to the current behavior.
>>> I am, for instance...
>
>> The varobj code will fail with file:line number breakpoint setting on
>> the { that starts the function. This is, of course, not a problem
>> for command-line gdb users, but varobj IS a part of gdb... Until we
>> have the CFI stuff well enough set up that, on landing at the
>> beginning of the prologue, the scanner will tell us where the stack
>> frame WILL be when it has been set up so we can record this properly,
>> this will be a problem.
>
> Aren't varobj/MI and the CLI separate? varobj/MI could easily request
> a prologue adjusted breakpoint without modifying the CLI.
>
> enjoy,
> Andrew
>
>
>
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham
jingham@apple.com
Developer Tools - gdb
next prev parent reply other threads:[~2002-08-24 21:05 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1030059293.13128.ezmlm@sources.redhat.com>
2002-08-23 10:50 ` Jim Ingham
2002-08-23 11:34 ` Andrew Cagney
2002-08-24 18:31 ` Jim Ingham [this message]
2002-08-25 7:45 ` Andrew Cagney
2002-08-25 8:21 ` Daniel Jacobowitz
2002-08-25 15:24 ` Jim Ingham
2002-08-23 11:45 ` Michael Snyder
2002-08-23 11:48 ` Daniel Jacobowitz
[not found] <1029446396.15888.ezmlm@sources.redhat.com>
2002-08-15 15:26 ` Jim Ingham
2002-08-15 18:05 ` Andrew Cagney
2002-08-15 19:11 ` Joel Brobecker
2002-08-16 10:02 ` Jim Blandy
2002-08-16 10:17 ` Joel Brobecker
2002-08-15 19:18 ` Daniel Jacobowitz
2002-08-16 9:34 ` Jim Blandy
2002-08-16 11:34 ` Jim Ingham
2002-08-22 15:38 ` Michael Snyder
2002-08-22 15:56 ` Andrew Cagney
2002-08-22 16:34 ` Michael Snyder
[not found] <1028439120.16228.ezmlm@sources.redhat.com>
2002-08-06 13:37 ` Jim Ingham
2002-08-14 22:57 ` Andrew Cagney
2002-08-15 6:53 ` Daniel Jacobowitz
2002-08-22 15:33 ` Michael Snyder
2002-08-22 16:19 ` Joel Brobecker
2002-08-23 11:27 ` Daniel Jacobowitz
[not found] <1027384602.26926.ezmlm@sources.redhat.com>
2002-07-22 18:54 ` Jim Ingham
2002-07-22 22:49 ` Joel Brobecker
2002-07-22 17:36 Joel Brobecker
2002-07-23 16:53 ` Jim Blandy
2002-07-26 6:12 ` Joel Brobecker
2002-07-29 13:34 ` Daniel Jacobowitz
2002-07-29 23:57 ` Jim Blandy
2002-07-30 20:18 ` Joel Brobecker
2002-07-31 13:55 ` Jim Blandy
2002-08-01 15:44 ` Michael Snyder
2002-08-02 23:48 ` Jim Blandy
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=30A3EC98-B7A5-11D6-BB10-000A277A8808@apple.com \
--to=jingham@apple.com \
--cc=ac131313@ges.redhat.com \
--cc=gdb-patches@sources.redhat.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