From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15930 invoked by alias); 2 Apr 2012 14:17:26 -0000 Received: (qmail 15777 invoked by uid 22791); 2 Apr 2012 14:17:24 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 02 Apr 2012 14:17:08 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q32EGinh000398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Apr 2012 10:16:44 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q32EGhae031154; Mon, 2 Apr 2012 10:16:44 -0400 Message-ID: <4F79B4CB.4090903@redhat.com> Date: Mon, 02 Apr 2012 14:17:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120316 Thunderbird/11.0 MIME-Version: 1.0 To: Tristan Gingold CC: Jack Howarth , gdb@sourceware.org Subject: Re: PR13901 References: <20120330134210.GA7869@bromo.med.uc.edu> <14D51CD4-4990-4B11-952C-64EB8F791306@adacore.com> <4F79AFF4.9000704@redhat.com> <54AC9EED-A577-41CA-B09D-3ED879877D0C@adacore.com> In-Reply-To: <54AC9EED-A577-41CA-B09D-3ED879877D0C@adacore.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-04/txt/msg00009.txt.bz2 On 04/02/2012 03:06 PM, Tristan Gingold wrote: > > On Apr 2, 2012, at 3:56 PM, Pedro Alves wrote: >> Why does GDB need to touch the shell's registers at all in the first place? > > I haven't checked why. Well, I claim that it shouldn't. :-) The whole existence of fork-child.c:startup_inferior was justified on making GDB not touch the shell. We used to have the startup phase go through the whole wait_for_inferior shebang, which was problematic as it touched the shell. > >> If we can't skip darwin_set_sstep for all continues that are not single-steps, >> we could at least skip those while starting up (when continuing the shell >> until we see enough execs). That'd suggest a new flag like >> darwin-nat.h:struct private_inferior->starting_up, set and cleared in >> darwin_create_inferior, and then making darwin_resume_thread do: >> >> - /* Set single step. */ >> - inferior_debug (4, _("darwin_set_sstep (thread=%x, enable=%d)\n"), >> - thread->gdb_port, step); >> - darwin_set_sstep (thread->gdb_port, step); >> + /* Avoid touching the $SHELL process, and go straight to resuming it. */ >> + gdb_assert (!inf->private->starting_up || !step); >> + if (!inf->private->starting_up) >> + { >> + /* Set single step. */ >> + inferior_debug (4, _("darwin_set_sstep (thread=%x, enable=%d)\n"), >> + thread->gdb_port, step); >> + darwin_set_sstep (thread->gdb_port, step); >> >> WDYT? > > Yes, it might be cleaner. > > Honestly, I'd prefer to get rid of the shell step and directly execute the user program - or at least have an option to do that. I think I also understand the cons of this approach. I'd be glad to see STARTUP_WITH_SHELL turned into a run-time option. I think there's a PR open for that even. However, we need the shell at least for argument globbing, as in, e.g., debugging `ls *', so I don't think we could make it off by default, which practically renders it an orthogonal feature. -- Pedro Alves