From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5389 invoked by alias); 31 Aug 2004 14:41:45 -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 5321 invoked from network); 31 Aug 2004 14:41:42 -0000 Received: from unknown (HELO miranda.se.axis.com) (212.209.10.220) by sourceware.org with SMTP; 31 Aug 2004 14:41:42 -0000 Received: from [10.84.130.1] (ironmaiden.se.axis.com [10.84.130.1]) by miranda.se.axis.com (8.12.9/8.12.9/Debian-5local0.1) with ESMTP id i7VEeg05016315; Tue, 31 Aug 2004 16:40:43 +0200 Message-ID: <41348DEA.9040807@axis.com> Date: Tue, 31 Aug 2004 14:41:00 -0000 From: Orjan Friberg Organization: Axis Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 MIME-Version: 1.0 To: gdb-patches@sources.redhat.com CC: Daniel Jacobowitz Subject: Re: schedlock.exp questions References: <412B55E1.7040803@axis.com> <20040824145502.GA26280@nevyn.them.org> <412CABED.10108@axis.com> <20040825160315.GA31412@nevyn.them.org> <412F3E18.8030408@axis.com> In-Reply-To: <412F3E18.8030408@axis.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00781.txt.bz2 Orjan Friberg wrote: > Daniel Jacobowitz wrote: > >> >> This is a twisty and nasty part of infrun. It is full of bugs and >> things that need to be rearchitected. So it's quite likely it doesn't >> work right. I did some more thinking, and maybe what you suggest does apply here. The logic of it escapes me at least: * Breakpoint is set * Breakpoint is hit (by all threads) * Some random thread (?) is reported by the gdbserver as stopped * Breakpoint is deleted (leaving the other threads with a pending(*) SIGTRAP) Now, if a software single-step architecture (CRIS) is stepped, the pending SIGTRAPs are reported by the gdbserver, but because we are single-stepping thread_hop_needed is set in handle_inferior_event, making GDB ignore the signal. Eventually, when the single-step target is reached, we'll stop. However, if we issue a "continue" instead of a "step", the SIGTRAPs are *not* ignored, and GDB will show us as stopped due to a SIGTRAP at the now removed breakpoint for each of the threads. I fail to see why the behaviour in these two cases should be different. Is it because we can't stop half-way through an ongoing software single-step? For a hardware single-step architecture (CRISv32), the behaviour will be the same regardless of whether we "step" or "continue" - GDB will stop when the SIGTRAPs are received by the gdbserver. (*) pending in the sense that gdbserver hasn't informed GDB of it yet -- Orjan Friberg Axis Communications