From: Vladimir Prus <ghost@cs.msu.su>
To: Nick Roberts <nickrob@snap.net.nz>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [8/9] multiple locations
Date: Wed, 14 Nov 2007 11:58:00 -0000 [thread overview]
Message-ID: <200711141047.03166.ghost@cs.msu.su> (raw)
In-Reply-To: <18234.40538.721148.831465@kahikatea.snap.net.nz>
On Wednesday 14 November 2007 10:06:02 you wrote:
> > As I say in another email, I might be able to implement using <PENDING>
> > as address in all cases.
>
> I don't pretend to understand the code but the patch below seems to work
> for me (probably not all cases).
I believe that in a case of breakpoint with multiple locations, where
the first location is shlib_disabled, the updated code will print <PENDING>
as address, not <MULTIPLE>.
I think the right approach would be moving the check for loc->shlib_disabled later, like this:
if (b->loc == NULL)
ui_out_field_string (uiout, "addr", "<PENDING>");
else if (header_of_multiple)
ui_out_field_string (uiout, "addr", "<MULTIPLE>");
else if (loc->shlib_disabled)
ui_out_field_string (uiout, "addr", "<PENDING>");
else
ui_out_field_core_addr (uiout, "addr", loc->address);
But there's also testsuite to be updated and getting somebody to
actually approve this patch.
> > But generally, trying to keeping CLI back compatible have to stop
> > at some time -- if we keep this "don't break CLI clients even if
> > CLI clients were deprecated from some time" attitude, it will result
> > in new features being available via MI only.
>
> Focussing on the issue at hand, we're just talking about making a minor
> adjustment to the format of "info breakpoints", for the case of pending
> breakpoints, to avoid breaking existing frontend(s).
Not quite. We're trying to please frontend(s) using deprecated protocol.
However little time is spent on that, it's time not spent on other, better things.
Is there a reason Emacs website cannot say "Use MI support, available at http://..."?
- Volodya
next prev parent reply other threads:[~2007-11-14 11:58 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-13 7:15 Nick Roberts
2007-11-13 8:05 ` Vladimir Prus
2007-11-13 8:31 ` Nick Roberts
2007-11-13 8:45 ` Vladimir Prus
2007-11-13 12:38 ` Daniel Jacobowitz
2007-11-13 19:58 ` Vladimir Prus
2007-11-14 19:21 ` Jim Blandy
2007-11-13 22:20 ` Eli Zaretskii
2007-11-13 22:47 ` Joel Brobecker
2007-11-14 6:29 ` Vladimir Prus
2007-11-14 7:06 ` Nick Roberts
2007-11-14 11:58 ` Vladimir Prus [this message]
2007-11-14 19:18 ` Nick Roberts
2007-11-14 19:37 ` Joel Brobecker
2007-11-14 19:38 ` Vladimir Prus
2007-11-14 20:42 ` Nick Roberts
2007-11-14 21:17 ` Joel Brobecker
2007-11-15 20:39 ` Vladimir Prus
2007-11-16 20:37 ` Nick Roberts
2007-11-19 2:42 ` Nick Roberts
2007-11-14 18:56 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2007-09-07 22:49 Vladimir Prus
2007-09-07 22:51 ` Vladimir Prus
2007-09-08 11:46 ` Eli Zaretskii
2007-09-08 11:55 ` Vladimir Prus
2007-09-08 12:28 ` Eli Zaretskii
2007-09-22 19:53 ` Vladimir Prus
2007-09-23 4:13 ` Eli Zaretskii
2007-09-08 13:17 ` Mark Kettenis
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=200711141047.03166.ghost@cs.msu.su \
--to=ghost@cs.msu.su \
--cc=gdb-patches@sources.redhat.com \
--cc=nickrob@snap.net.nz \
/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