From: Vladimir Prus <ghost@cs.msu.su>
To: gdb@sources.redhat.com
Subject: Re: MI: output of -break-insert and -break-watch
Date: Fri, 17 Feb 2006 15:00:00 -0000 [thread overview]
Message-ID: <dt4ns5$3f7$1@sea.gmane.org> (raw)
In-Reply-To: <20060217141804.GA19339@nevyn.them.org>
Daniel Jacobowitz wrote:
> On Fri, Feb 17, 2006 at 05:13:52PM +0300, Vladimir Prus wrote:
>> > I don't get it. Why is this a problem? It sounds to me like the only
>> > reason this would be awkward would be limitations of your front end.
>> > If you've done -break-insert you should expect a bkpt response, if
>> > you've done -break-watch you should expect a wpt response.
>>
>> Here's the code I use now to extract breakpoint id from response:
>>
>> int id = -1;
>>
>> if (r.hasField("bkpt"))
>> id = r["bkpt"]["number"].literal().toInt();
>> else if (r.hasField("wpt"))
>> id = r["wpt"]["number"].literal().toInt();
>> else if (r.hasField("hw-rwpt"))
>> id = r["hw-rwpt"]["number"].literal().toInt();
>>
>> And there's also "hw-awpt", and in future there might be "catchpoint" and
>> "fork" and what not.
>>
>> If I only want to extract the *id* of breakpoint, why do I need to write
>> such boilerplate? Or should I write a function that will iterate over all
>> fields of 'r', and check if that field has nested field called 'number'?
>
> This still sounds to me like it has more to do with the architecture of
> your front-end than it does with meaningful layout of MI.
Well, I'm not sure it's specific to KDevelop:
1. All frontends will want to know the id of the set breakpoint, as that's
the only information that allows to modify the breakpoint later.
2. The above "bkpt" and so on are MI-specific names which must be hardcoded
in frontend somewhere.
> This is only
> about the response to -break-insert and -break-watch as far as I
> understand. So if you want to avoid the conditional, you can record
> which type to expect when you issue the command.
And if I have to remember the type of breakpoint command I've sent, then
what's the use of the different naming of field in reply -- it clearly not
need to recover the type of breakpoint, as I've already remembered it.
> Or leave the conditional; it's not that bad, is it?
Well, it just got another "if" clause for "hw-awpt", and I'd expect this to
grow by a couple over time. No, it's no a big architectural thing, but
still an annoyance.
- Volodya
prev parent reply other threads:[~2006-02-17 14:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-17 12:37 Vladimir Prus
2006-02-17 13:53 ` Eli Zaretskii
2006-02-17 14:03 ` Vladimir Prus
2006-02-17 13:56 ` Daniel Jacobowitz
2006-02-17 14:14 ` Vladimir Prus
2006-02-17 14:24 ` Daniel Jacobowitz
2006-02-17 14:18 ` Daniel Jacobowitz
2006-02-17 15:00 ` Vladimir Prus [this message]
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='dt4ns5$3f7$1@sea.gmane.org' \
--to=ghost@cs.msu.su \
--cc=gdb@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