From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3974 invoked by alias); 23 Aug 2002 20:15:05 -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 3967 invoked from network); 23 Aug 2002 20:15:03 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 23 Aug 2002 20:15:03 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17iKpm-0001xn-00; Fri, 23 Aug 2002 15:15:07 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17iKqT-0007vV-00; Fri, 23 Aug 2002 16:15:49 -0400 Date: Fri, 23 Aug 2002 13:15:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: RFC: Two small remote protocol extensions Message-ID: <20020823201549.GB26809@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com 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> <3D6692AE.90601@ges.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D6692AE.90601@ges.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-08/txt/msg00307.txt.bz2 On Fri, Aug 23, 2002 at 03:53:18PM -0400, Andrew Cagney wrote: > > >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.). Let me see... sol_thread_resume: inferior_ptid = thread_to_lwp (inferior_ptid, PIDGET (main_ph.ptid)); procfs_resume: /* Find procinfo for main process */ pi = find_procinfo_or_die (PIDGET (inferior_ptid), 0); After that if PIDGET (ptid) == -1, it operates on the procinfo it got from inferior_ptid. Which is an LWP. I'm not sure precisely that will happen if you resume a specific LWP under Solaris; presumably it will resume that LWP's "current" thread in some sense, I don't know if that will behave predictably or not. I'm not familiar with Solaris threads. > 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 :-? Sure. I suppose we should clean up the interface to resume, to prevent all this confusion re-arising... which means figuring out our possible behaviors, and whether they are even implementable on particular targets. On Linux the options for any given LWP (at the moment, that means for any given thread) are step, run, stop. All combinations are available. I think the _useful_ ones are: step one, stop others step one, continue others continue one, stop others continue one, continue others And, of course: stop one, stop others :) Something like: resume (ptid, step, run_others, target_signal) maybe? Does anyone think step_all is useful (I don't)? PS: Some day letting the user be more precise (run these two threads) would be nice. I envision a day in the distant future: -> Continue thread 1 -> Continue thread 2 -> Wait for inferior status <- All threads stopped, thread 1, SIGSEGV or -> Continue all threads -> Wait for inferior status [maybe implicit in the all-threads request] <- Thread 1 stopped, shared lib breakpoint, all other threads running But let's not try to design to that quite yet :) -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer