From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17061 invoked by alias); 23 Aug 2002 19:53:22 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 17054 invoked from network); 23 Aug 2002 19:53:21 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 23 Aug 2002 19:53:21 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 296713ED7; Fri, 23 Aug 2002 15:53:18 -0400 (EDT) Message-ID: <3D6692AE.90601@ges.redhat.com> Date: Fri, 23 Aug 2002 12:53:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020810 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: RFC: Two small remote protocol extensions References: <20020502022543.GA22594@nevyn.them.org> <20020816143040.GA22041@nevyn.them.org> <3D5D0F62.4010207@ges.redhat.com> <20020816145306.GA24002@nevyn.them.org> <3D65B53D.8050603@ges.redhat.com> <20020823124453.GA12257@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00304.txt.bz2 > Inferior_ptid is set in this case. That's the whole problem; they have > access to it, but the remote implementation doesn't. The code from > lin-lwp: > > /* Apparently the interpretation of PID is dependent on STEP: If > STEP is non-zero, a specific PID means `step only this process > id'. But if STEP is zero, then PID means `continue *all* > processes, but give the signal only to this one'. */ > resume_all = (PIDGET (ptid) == -1) || !step; > > if (resume_all) > iterate_over_lwps (resume_set_callback, NULL); > else > iterate_over_lwps (resume_clear_callback, NULL); > > /* If PID is -1, it's the current inferior that should be > handled specially. */ > if (PIDGET (ptid) == -1) > ptid = inferior_ptid; > > (I'm not quite sure about that comment; that might want to be revisited > later... there should be a way to continue just one process. I thought > I remembered that working, but I must have been mistaken.) Hmm, I'm more interested in Solaris (since that target has a thread model which allows control of the entire thread group). With that one, I couldn't find an equivalent operation (I've probably missed it.). It's just really wierd (wrong?) that one layer of GDB thinks that it only needs to specify the step thread when doing the thread hop, yet the next layer down finds it necessary to always specify the step thread :-? Andrew