From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3464 invoked by alias); 8 Apr 2003 18:53:38 -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 3456 invoked from network); 8 Apr 2003 18:53:37 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 8 Apr 2003 18:53:37 -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 h38Irbe22095 for ; Tue, 8 Apr 2003 14:53:37 -0400 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 h38IrbJ32552 for ; Tue, 8 Apr 2003 14:53:37 -0400 Received: from localhost.redhat.com (romulus-int.sfbay.redhat.com [172.16.27.46]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h38Iram24952 for ; Tue, 8 Apr 2003 14:53:37 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id 94C902C43E; Tue, 8 Apr 2003 14:57:54 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16019.7089.874783.321173@localhost.redhat.com> Date: Tue, 08 Apr 2003 18:53:00 -0000 To: gdb-patches@sources.redhat.com Cc: Subject: Re: [RFC] PTRACE_ATTACH problem on new Linux kernels In-Reply-To: <15954.39904.805543.819269@localhost.redhat.com> 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> X-SW-Source: 2003-04/txt/msg00132.txt.bz2 Elena Zannoni writes: > Andrew Cagney writes: > > > Andrew Cagney writes: > > > > Solution 0 is to discard the STOP in infrun.c as part of the stop > > > > analyzis. > > > > > > > > > > Yes, but I am not sure it won't break the other cases that share that > > > stop analysis. The stop_soon_quietly variable is relied upon in other > > > places, like the start_remote function, the startup_inferior function, > > > the sharedlib machinery. That's why I thought the handling it in the > > > attach command would be safer. > > > > It certainly doesn't break anything, however, it also makes the long > > term problem harder. > > > > > > > A first solution could be that upon continuing, gdb never sends a > > > > > SIGSTOP through the ptrace call. I.e. the stop_signal in > > > > > ptrace(PTRACE_CONT, pid, stop_signal) could be changed to > > > > > TARGET_SIGNAL_0 if it is TARGET_SIGNAL_STOP (such a call is in > > > > > proceed(), and we already do some signal munging there). > > > > > > > > > > Another solution is to throw away the TARGET_SIGNAL_STOP that is saved > > > > > in stop_signal when we do an attach. This would be in > > > > > attach_command(), in infcmd.c. This way it would not come into play at > > > > > all at the next continue. > > > > > > > > This will make the desperatly needed objective of trying to eliminate > > > > the global stop_signal variable just that bit more difficult. > > > > > > > > If the already nasty hacks in HP/PA and solib code is ignored, the > > > > only places stop_signal is modified is in infrun.c. > > > > > > > > > > Hmm true, sigh. > > > > Think about the frames code where things got so complicated that no one > > was game to change it. > > With the changes in place I'm now finding my self fighting a rear-guard > > action to stop the old hacks re-appearing. > > > > > > > Yet another solution is that we 'hide' the TARGET_SIGNAL_STOP in > > > > > child_resume(), in i386-linux-nat.c but this would not be applicable > > > > > to the other linux arches. > > > > > > > > Or discard the signal in resume()? > > > > > > > > > > yes, proceed() already does something like that, but that would mean > > > that we modify the signal before doing the continue, and not after we > > > receive it. There is a lot that can happen between issuing an > > > 'attach' command, and a later 'continue'. Maybe we would be discarding > > > a valid SIGSTOP to pass to the inferior. > > > > > > I think the only option left is to change the handle_inferior_event > > > stop analysis, which is scary... > > > > Conceptually, the code is being used as: > > > > - connect to target > > - force the WFI state machine into a specific initial state (stop > > normally, stop_soon_quietly or, now, stop_soon_with_sigstop) (yes, ok, > > no one believes me when I say that WFI is a state machine :-) > > - run the WFI state machine to analize the target's state > > > > Can stop_soon_quietly be [ab]used / extended to in a more general way > > force WFI into other states? Either by treating it as bit fields or as > > alternative states? e.g., > > > > enum stop_soon { stop_soon_normally, stop_soon_quietly, > > stop_soon_suspended }; > > > > or struct stop_soon { int quietly; int suspended; } > > > > or ... > > > > Andrew > > > > > > Kind of. I am testing the following: > > 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. > > I finally committed this. I'll do another round changing the name of stop_soon_quietly to stop_soon, as Kevin suggested. elena