From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20625 invoked by alias); 2 Apr 2012 14:25:35 -0000 Received: (qmail 20608 invoked by uid 22791); 2 Apr 2012 14:25:34 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (194.98.77.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 02 Apr 2012 14:25:18 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 614C6290086; Mon, 2 Apr 2012 16:25:22 +0200 (CEST) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzLDTWZzBm9W; Mon, 2 Apr 2012 16:25:22 +0200 (CEST) Received: from ulanbator.act-europe.fr (ulanbator.act-europe.fr [10.10.1.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id E285429007A; Mon, 2 Apr 2012 16:25:21 +0200 (CEST) Subject: Re: PR13901 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Tristan Gingold In-Reply-To: <4F79B4CB.4090903@redhat.com> Date: Mon, 02 Apr 2012 14:25:00 -0000 Cc: Jack Howarth , gdb@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <2FC589F0-E66A-4464-A93D-D8F532B24917@adacore.com> 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> <4F79B4CB.4090903@redhat.com> To: Pedro Alves X-IsSubscribed: yes 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/msg00011.txt.bz2 On Apr 2, 2012, at 4:16 PM, Pedro Alves wrote: > On 04/02/2012 03:06 PM, Tristan Gingold wrote: >=20 >>=20 >> On Apr 2, 2012, at 3:56 PM, Pedro Alves wrote: >=20 >=20 >>> Why does GDB need to touch the shell's registers at all in the first pl= ace? >>=20 >> I haven't checked why. >=20 >=20 > 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. >=20 >>=20 >>> 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 she= ll >>> 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: >>>=20 >>> - /* Set single step. */ >>> - inferior_debug (4, _("darwin_set_sstep (thread=3D%x, enable=3D%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=3D%x, enable= =3D%d)\n"), >>> + thread->gdb_port, step); >>> + darwin_set_sstep (thread->gdb_port, step); >>>=20 >>> WDYT? >>=20 >> Yes, it might be cleaner. >>=20 >> Honestly, I'd prefer to get rid of the shell step and directly execute t= he user program - or at least have an option to do that. I think I also un= derstand the cons of this approach. >=20 >=20 > I'd be glad to see STARTUP_WITH_SHELL turned into a run-time option. Good to know that. > I think there's > a PR open for that even. However, we need the shell at least for argumen= t globbing, > as in, e.g., debugging `ls *', so I don't think we could make it off by d= efault, > which practically renders it an orthogonal feature. Sure. Tristan.