From: Pawel Piech <pawel.piech@windriver.com>
To: Vladimir Prus <vladimir@codesourcery.com>
Cc: gdb@sources.redhat.com
Subject: Re: MI non-stop interface details
Date: Thu, 01 May 2008 16:58:00 -0000 [thread overview]
Message-ID: <4819F64A.3020006@windriver.com> (raw)
In-Reply-To: <fvcrka$3pn$1@ger.gmane.org>
Vladimir Prus wrote:
> Pawel Piech wrote:
>
>
>> Vladimir Prus wrote:
>>
>>> On Tuesday 29 April 2008 22:03:20 Pawel Piech wrote:
>>>
>>>
>>>> Pedro Alves wrote:
>>>>
>>>>
>>>>> I can't see how is it different -- in the frontend's perspective --
>>>>> of keeping track of what to pass to --thread= *provided GDB doesn't switch
>>>>> threads automatically*. But then again, I'm no frontend writer.
>>>>>
>>>>>
>>>>>
>>>> Using -thread-select makes it easier for the front end to be compatible
>>>> with older versions of GDB.
>>>>
>>>>
>>> Hmm, I though that only reason that -thread-select is simpler is because
>>> in DSF, specifically, there's no central place where commands are send
>>> and where --thread can be conveniently added. I'm not saying this is good,
>>> or bad, but this is not the case for all frontend. Am I wrong?
>>>
>>> - Volodya
>>>
>>>
>> In DSF-GDB there _is_ a central place where commands are sent, this is
>> where the protocol state is adjusted using -thread-select. However, the
>> --thread option is being added to many but not all commands, so the same
>> mechanism that adds the -thread-select could not be reused to add
>> --thread option. Instead each command which accepts --thread that would
>> need to be adjusted to use the --thread, but only when in non-stop
>> debugging mode.
>>
>
> This is not actually. The plan is for eery command will accept --thread.
> Those that don't have any use of it will ignore it. The only command,
> at the moment, for which the meaning of --thread is not yet clear, and for
> which the frontend might have to have custom decision logic, is --exec-continue.
>
> - Volodya
>
That's helpful. Unfortunately UI clients that want to have a wide user
base still need to worry about old GDB versions which do not support
-thread, and that was my first point in this thread. As I've seen on
this mailing list there are users out there still on GDB 5.x. I expect
it will take several years before support for GDB 6.8 and prior is not
so important.
-Pawel
next prev parent reply other threads:[~2008-05-01 16:58 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-26 18:09 Vladimir Prus
2008-04-26 18:16 ` Doug Evans
2008-04-26 19:49 ` Vladimir Prus
2008-04-30 7:18 ` Marc Khouzam
2008-04-28 16:21 ` Pedro Alves
2008-04-29 19:21 ` Vladimir Prus
2008-04-29 20:04 ` Pedro Alves
2008-04-30 7:00 ` Pawel Piech
2008-05-01 16:15 ` Vladimir Prus
2008-05-01 16:31 ` Pawel Piech
2008-05-01 16:38 ` Vladimir Prus
2008-05-01 16:58 ` Pawel Piech [this message]
[not found] ` <4819F4D4.4010305@windriver.com>
2008-05-01 17:00 ` Vladimir Prus
2008-05-01 17:53 ` Pawel Piech
2008-05-01 18:12 ` Vladimir Prus
2008-05-01 18:37 ` Pawel Piech
2008-05-02 1:23 ` Evolution of GDB/MI [was Re: MI non-stop interface details] Nick Roberts
2008-04-30 14:23 ` MI non-stop interface details Marc Khouzam
2008-04-30 17:21 ` Pedro Alves
[not found] ` <200804301117.42633.vladimir@codesourcery.com>
[not found] ` <4818AA58.4040201@windriver.com>
2008-05-01 17:11 ` Vladimir Prus
2008-05-01 18:08 ` Pawel Piech
2008-05-02 14:21 ` Vladimir Prus
2008-05-02 16:59 ` Pawel Piech
2008-05-02 17:13 ` Vladimir Prus
[not found] ` <481B4FDC.4010802@windriver.com>
2008-05-02 17:36 ` Vladimir Prus
2008-05-02 18:00 ` Pawel Piech
2008-05-02 18:19 ` Vladimir Prus
2008-05-02 18:36 ` Pawel Piech
2008-04-29 3:14 ` Pawel Piech
[not found] ` <200804301059.44112.vladimir@codesourcery.com>
[not found] ` <200804301534.48779.pedro@codesourcery.com>
2008-05-01 17:22 ` Vladimir Prus
2008-05-01 17:52 ` Pedro Alves
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=4819F64A.3020006@windriver.com \
--to=pawel.piech@windriver.com \
--cc=gdb@sources.redhat.com \
--cc=vladimir@codesourcery.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