From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12531 invoked by alias); 23 Aug 2002 04:08:32 -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 12524 invoked from network); 23 Aug 2002 04:08:31 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 23 Aug 2002 04:08:31 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 470B53C48; Fri, 23 Aug 2002 00:08:29 -0400 (EDT) Message-ID: <3D65B53D.8050603@ges.redhat.com> Date: Thu, 22 Aug 2002 21:08: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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00280.txt.bz2 > This one, however, needs feedback. A user just reported a bogus >> >SIGTRAP bug to me which is fixed by the above. >> > >> >To elaborate on the problem: right now we have two ways of specifying a >> >thread to the remote agent. Hg specifies the "general" thread, and Hc >> >specifies the "continue" thread. These correspond to inferior_ptid and >> >resume_ptid, roughly. >> > >> >When we single-step, if we are not using some form of >> >scheduler-locking, resume_ptid is 0. We don't tell the agent at that >> >point what inferior_ptid is; it has to step _some_ thread, and it picks >> >one, and if it doesn't pick the one GDB expected we get problems. I think it is passed down when schedule locking and when doing a thread hop. I'm wondering how native thread implementations handle your case? I don't see how remote_resume(), or any of the other resume functions can know which thread to step since the only parameter available to them is resume-ptid and you're indicating that that is NULL. Andrew