From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22032 invoked by alias); 8 Jul 2008 01:59:02 -0000 Received: (qmail 22019 invoked by uid 22791); 8 Jul 2008 01:59:01 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 08 Jul 2008 01:58:36 +0000 Received: (qmail 18890 invoked from network); 8 Jul 2008 01:58:35 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 8 Jul 2008 01:58:35 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [gdbserver] Fix attaching notices Date: Tue, 08 Jul 2008 01:59:00 -0000 User-Agent: KMail/1.9.9 Cc: Daniel Jacobowitz References: <200806280011.12868.pedro@codesourcery.com> <20080707175510.GB1778@caradoc.them.org> <200807080051.46088.pedro@codesourcery.com> In-Reply-To: <200807080051.46088.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807080258.34187.pedro@codesourcery.com> X-IsSubscribed: yes 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 X-SW-Source: 2008-07/txt/msg00106.txt.bz2 A Tuesday 08 July 2008 00:51:45, Pedro Alves wrote: > You're right, I just tried with 6.8 too, and don't see the SIGTRAP > notice... I'll try to pinpoint what changed this, and see if it > was a spurious change. > Unsurprisingly, > 2008-05-01 Daniel Jacobowitz > Pedro Alves > > Based on work by Jan Kratochvil and Jeff > Johnston . > > * NEWS: Mention attach to stopped process fix. > * infcmd.c (detach_command, disconnect_command): Discard the thread > list. > * infrun.c (handle_inferior_event): Do not ignore non-SIGSTOP while > attaching. Use signal_stop_state. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > (signal_stop_state): Check stop_soon. > * linux-nat.c (kill_lwp): Declare earlier. > (pid_is_stopped, linux_nat_post_attach_wait): New. > (lin_lwp_attach_lwp): Use linux_nat_post_attach_wait. Update > comments. > (linux_nat_attach): Use linux_nat_post_attach_wait. > (detach_callback, linux_nat_detach): Improve handling for signalled > processes. > (linux_nat_pid_to_str): Always print out the LWP ID if it differs > from the process ID. > * Makefile.in (infcmd.o): Update. Before, /* This originates from attach_command(). We need to overwrite the stop_signal here, because some kernels don't ignore a SIGSTOP in a subsequent ptrace(PTRACE_SONT,SOGSTOP) call. See more comments in inferior.h. */ if (stop_soon == STOP_QUIETLY_NO_SIGSTOP) { stop_stepping (ecs); if (stop_signal == TARGET_SIGNAL_STOP) stop_signal = TARGET_SIGNAL_0; return; } After, /* This originates from attach_command(). We need to overwrite the stop_signal here, because some kernels don't ignore a SIGSTOP in a subsequent ptrace(PTRACE_CONT,SIGSTOP) call. See more comments in inferior.h. On the other hand, if we get a non-SIGSTOP, report it to the user - assume the backend will handle the SIGSTOP if it should show up later. */ if (stop_soon == STOP_QUIETLY_NO_SIGSTOP && stop_signal == TARGET_SIGNAL_STOP) { stop_stepping (ecs); stop_signal = TARGET_SIGNAL_0; return; } Since gdbserver is reporting a TARGET_SIGNAL_TRAP, this now doesn't match, and we go on handling the event until we decide it was a random signal. So, we either 1) go with my patch (on which the win32 part was a hack, but I can live with it), and live with the bogus notice against older gdbservers, or 2) change the test to: if (stop_soon == STOP_QUIETLY_NO_SIGSTOP && stop_signal == TARGET_SIGNAL_STOP && stop_signal == TARGET_SIGNAL_TRAP) { stop_stepping (ecs); stop_signal = TARGET_SIGNAL_0; return; } Or even add a `&& stop_signal == TARGET_SIGNAL_0', and merge this stop_soon with STOP_QUIETLY_REMOTE. 3) other? -- Pedro Alves