From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76835 invoked by alias); 11 Sep 2017 22:08:17 -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 76822 invoked by uid 89); 11 Sep 2017 22:08:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy= X-HELO: mail.baldwin.cx Received: from bigwig.baldwin.cx (HELO mail.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 11 Sep 2017 22:08:13 +0000 Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 6EFB510A7B9; Mon, 11 Sep 2017 18:08:11 -0400 (EDT) From: John Baldwin To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Add a 'starti' command. Date: Mon, 11 Sep 2017 22:08:00 -0000 Message-ID: <1591205.ggSOSD9WHz@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <37591d57-19d9-4b20-9c93-2e2abae9aa70@redhat.com> References: <20170829225457.66096-1-jhb@FreeBSD.org> <2289243.bE5E4p8koA@ralph.baldwin.cx> <37591d57-19d9-4b20-9c93-2e2abae9aa70@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00317.txt.bz2 On Monday, September 04, 2017 11:57:26 AM Pedro Alves wrote: > > On 09/01/2017 10:42 PM, John Baldwin wrote: > > On Thursday, August 31, 2017 11:51:33 PM Pedro Alves wrote: > >> Hi John, > >> > >> On 08/30/2017 12:54 AM, John Baldwin wrote: > >>> This works like 'start' but it stops at the first instruction rather than > >>> the first line in main(). This is useful if one wants to single step > >>> through runtime linker startup. > >> > >> I like the idea. I actually once wrote a patch quite similar to this. > >> I had called the command "create", inspired by "target_create_inferior". > >> Is there a reason to actually set a breakpoint at the first instruction and > >> run to it, actually? My old prototype just created the inferior and > >> didn't resume it all, see: > >> > >> https://github.com/palves/gdb/commits/create_command > >> > >> though maybe going through normal_stop may be a good idea. > > I should expand on this sentence above. I was thinking of thinks like, > should a user-defined hook-stop run in this case? Probably. Going > via "normal_stop" makes sure that is handled. My old prototype would > skip any hook-stop (and I don't recall whether I did that on purpose.) > > This suggests to me that it'd be good to have a test making sure > we either run the hook-stop or not, whatever we decide should happen. Ok, I included hook-stop in my test. > > I tried this today and ended up with gdb hung in poll() but not printing a > > prompt or accepting commands still, so I've left it as a breakpoint. > > Another option is still go via process/normal_stop, but make sure that > the thread won't really be run by queing a pending status. Like so: > > if (/* starti mode*/) > { > // queue a pending event instead of setting a breakpoint at "*$pc". > thread_info *thr = inferior_thread (); > thr->suspend.waitstatus_pending_p = 1; > thr->suspend.waitstatus.kind = TARGET_WAITKIND_STOPPED; > thr->suspend.waitstatus.value.sig = GDB_SIGNAL_0; > } Yes, I like this and have adopted it. > One difference this makes is that this way the inferior doesn't really > ever get a chance to run. If a signal in nostop+pass state is queued > between creating the process and running to the breakpoint at "*$pc", > the signal handler (if any), runs. With the pending event approach, > it won't. Technically I don't think a program can register a signal handler without executing an instruction, but I think the above approach is cleaner regardless. -- John Baldwin