From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27127 invoked by alias); 3 Jun 2008 15:42:34 -0000 Received: (qmail 27115 invoked by uid 22791); 3 Jun 2008 15:42:33 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 03 Jun 2008 15:42:15 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 25B9B983F8 for ; Tue, 3 Jun 2008 15:42:13 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id F308498371 for ; Tue, 3 Jun 2008 15:42:12 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1K3YeJ-0004wS-Vz for gdb@sourceware.org; Tue, 03 Jun 2008 11:42:12 -0400 Date: Tue, 03 Jun 2008 15:42:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: Re: multi-process remote protocol extensions Message-ID: <20080603154211.GA18375@caradoc.them.org> Mail-Followup-To: gdb@sourceware.org References: <200805272233.24078.pedro@codesourcery.com> <20080603012736.GA25423@caradoc.them.org> <200806031620.28942.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200806031620.28942.pedro@codesourcery.com> User-Agent: Mutt/1.5.17 (2008-05-11) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-06/txt/msg00007.txt.bz2 On Tue, Jun 03, 2008 at 04:20:28PM +0100, Pedro Alves wrote: > Or: > > pPID.lLWP.TID > oOTHERNAMESPACE.pPID.lLWP.TID > > p999.123 > p999.l1.123 > > Can only use letters > f then, but that shouldn't be a problem? I like this one, though I would only define p for the moment. A whole process becomes "p99" and the special ".-1" can go away. > Yes, all-stop. I don't think you're saying a change is not > needed here. But for avoidance of doubt, the thread here must > also specify the pid (that's `12.' in the example), otherwise > GDB can't tell which process thread 2 belongs to. Right. > > (Jim's progress reporting work - you may > > remember the discussion of this but it's not finished). > > Hmm, I don't seem to remember this. Was this a public discussion? Nope. I'll point you to it. > > But for non-stop mode we could report them as ordinary events in the same > way > > as process exit. So, a hypothetical: > > > > `W AA [; thread:THREAD.ID]' > > > > Yes. > > Not stricly multi-process related, but while we're at it, two > nibbles `AA' only is unnecessarilly limiting. That was > the other reason for proposing new status packets. Allow more than just two nibbles if gdb supports the semicolon? > > I agree that we should add a new packet to replace 'k'. I'm not sure > > about 'D'; there's nothing else wrong with it, so I am not inclined to > > deprecate it. > > So, do a) for D ? > > D;process:PID Yes, I think so. > > Will vKill have any meaning connected to a non-multiprocess stub? If > > so we should clearly document it (e.g. CPU reset, single core reset, > > whatever). > > > > No reset: > > vKill;PID - kills process PID, in an OS sense. Get rid of > process PID. > > But can be: > vKill;process:PID - kills process PID. > vKill;thread:ID - kills thread ID, where ID can be an extended > pid.tid (or whatever comes decided) form in > multi-process aware stubs. I don't think allowing kills of a specific thread is useful. Probably some systems will not be able to implement it. > I'm not sure we should put resets on the same boat as kills. > Killing a process or a thread should have a reply. It isn't > specified currently if the packets requires a reply or not. > gdbserver doesn't send one, and GDB doesn't expect one. > > A reset on the core the stub is running, may have the effect that > it's not always possible for a packet acknowledge to be flushed > on the stub side, and GDB never gets the answer. > > Maybe that should be kept a separate packet, similar in vein > to R - restart - vReset/vRestart, > > vReset;core:ID - resets core ID (-1 all cores). This packet > has no reply. Anyway, let's define that vKill is only used for processes today. Sound OK? -- Daniel Jacobowitz CodeSourcery