From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32761 invoked by alias); 19 Feb 2003 17:40:57 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 32753 invoked from network); 19 Feb 2003 17:40:57 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 19 Feb 2003 17:40:57 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h1JHevK10002 for ; Wed, 19 Feb 2003 12:40:57 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h1JHeva05388 for ; Wed, 19 Feb 2003 12:40:57 -0500 Received: from localhost.localdomain (vpn50-1.rdu.redhat.com [172.16.50.1]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h1JHeuO20681; Wed, 19 Feb 2003 12:40:56 -0500 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h1JHep408765; Wed, 19 Feb 2003 10:40:51 -0700 Date: Wed, 19 Feb 2003 17:40:00 -0000 From: Kevin Buettner Message-Id: <1030219174050.ZM8764@localhost.localdomain> In-Reply-To: Elena Zannoni "Re: [RFC] PTRACE_ATTACH problem on new Linux kernels" (Feb 18, 3:47pm) References: <15953.34032.985446.344226@localhost.redhat.com> <20030218022401.14C7E3CF3@localhost.redhat.com> <15953.43345.841483.153044@localhost.redhat.com> <3E52936A.3060706@redhat.com> <15954.39904.805543.819269@localhost.redhat.com> To: Elena Zannoni Subject: Re: [RFC] PTRACE_ATTACH problem on new Linux kernels Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-02/txt/msg00421.txt.bz2 On Feb 18, 3:47pm, Elena Zannoni wrote: > 2003-02-18 Elena Zannoni > > * infrun.c (stop_soon_quietly): Make it an enum, to better > override the default behavior of handle_inferior_event. > (clear_proceed_status): Update uses of stop_soon_quietly to > reflect that it is now an enum. > (start_remote): Ditto. > (handle_inferior_event): Change logic a bit if stop_soon_quietly > is set to handle the new kernel behavior for attach/sigstop. > Update uses of stop_soon_quietly. > * inferior.h (enum stop_kind): New enum. > * infcmd.c (attach_command): Use STOP_QUIETLY_NO_SIGSTOP. > Reset normal handle_inferior_event behavior, afterwards. > * fork-child.c (startup_inferior): Update. > * alpha-tdep.c (heuristic_proc_start): Update. > * solib-svr4.c (svr4_solib_create_inferior_hook): Update. > * solib-sunos.c (sunos_solib_create_inferior_hook): Update. > * solib-osf.c (osf_solib_create_inferior_hook): Update. > * solib-irix.c (irix_solib_create_inferior_hook): Update. > * remote-vx.c (vx_create_inferior): Update. > * mips-tdep.c (heuristic_proc_start): Update. The solib portions of this patch are approved. I do wonder though if the ``stop_soon_quietly'' variable ought to be renamed. When it was a boolean, the name made sense, now that it's enum, things like if (stop_soon_quietly == NO_STOP_QUIETLY) don't look quite right, whereas if (!stop_soon_quietly) did. (Maybe just drop the _quietly suffix?) Kevin