From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12692 invoked by alias); 20 Aug 2014 12:00:40 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 12682 invoked by uid 89); 20 Aug 2014 12:00:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 20 Aug 2014 12:00:38 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s7KC0XFC020596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 20 Aug 2014 08:00:34 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7KC0U4r021182; Wed, 20 Aug 2014 08:00:31 -0400 Message-ID: <53F48DDE.3010108@redhat.com> Date: Wed, 20 Aug 2014 12:00:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Gary Benson , gdb-patches@sourceware.org CC: Doug Evans , Tom Tromey Subject: Re: [PATCH 05/11 v5] Add target/target.h References: <1406888377-25795-1-git-send-email-gbenson@redhat.com> <1406888377-25795-6-git-send-email-gbenson@redhat.com> In-Reply-To: <1406888377-25795-6-git-send-email-gbenson@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-08/txt/msg00394.txt.bz2 (Reviewing in pieces) On 08/01/2014 11:19 AM, Gary Benson wrote: > +/* See target/target.h. */ > + > +int > +target_read_uint32 (CORE_ADDR memaddr, unsigned int *result) > +{ The type of 'result' should be uint32_t then. > + > +/* Resume execution of the target process PTID (or a group of > + threads). STEP says whether to single-step or to run free; SIGGNAL > + is the signal to be given to the target, or GDB_SIGNAL_0 for no > + signal. The caller may not pass GDB_SIGNAL_DEFAULT. A specific > + PTID means `step/resume only this process id'. A wildcard PTID > + (all threads, or all threads of process) means `step/resume > + INFERIOR_PTID, and let other threads (for which the wildcard PTID > + matches) resume with their 'thread->suspend.stop_signal' signal > + (usually GDB_SIGNAL_0) if it is in "pass" state, or with no signal > + if in "no pass" state. */ Most of this comment doesn't make any sense for gdbserver, and I don't ever will. (GDBserver's resume interface is more flexible than gdb's.) There's no inferior_ptid in gdbserver. There's no thread->suspend.stop_signal. In the gdbserver implemention this adds: > + resume_info.thread = ptid; > + resume_info.kind = step ? resume_step : resume_continue; > + resume_info.sig = signal; > + (*the_target->resume) (&resume_info, 1); ... when STEP is true and PTID is a wildcard, what this actually does is tell the target to step each thread in the wildcard, all in parallel. I think we should instead add a new 'target_continue_ptid (ptid_t ptid)' method, that then consumes/calls gdb's target_resume in gdb's implementation, and gdbserver's '(*the_target->resume) (&resume_info, 1);' in the gdbserver implementation? > + > +extern void target_resume (ptid_t ptid, int step, enum gdb_signal signal); Thanks, Pedro Alves