From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12323 invoked by alias); 27 Aug 2004 13:59:29 -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 12306 invoked from network); 27 Aug 2004 13:59:24 -0000 Received: from unknown (HELO miranda.se.axis.com) (193.13.178.2) by sourceware.org with SMTP; 27 Aug 2004 13:59:24 -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 i7RDwm9P028259; Fri, 27 Aug 2004 15:58:49 +0200 Message-ID: <412F3E18.8030408@axis.com> Date: Fri, 27 Aug 2004 13:59: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: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com Subject: Re: schedlock.exp questions References: <412B55E1.7040803@axis.com> <20040824145502.GA26280@nevyn.them.org> <412CABED.10108@axis.com> <20040825160315.GA31412@nevyn.them.org> In-Reply-To: <20040825160315.GA31412@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00733.txt.bz2 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. Ok, I think I got the hang of it now. (Apologies if my ramblings below are a tad long-winded.) The actual problem for CRISv32 is that the SIGTRAPs resulting from the "break 41 if arg!=5" breakpoint for the other threads aren't ignored, and that seems to be due to that it's using hardware single-step. This what happens: in schedlock.exp, after the first "break 41 if arg != 5" breakpoint is hit, all breakpoints are removed. When we step the current thread afterwards, the other threads all have a pending SIGTRAP (since they also hit that same (now removed) breakpoint). At this point we reach the following code (infrun.c:handle_inferior_event): /* See if a thread hit a thread-specific breakpoint that was meant for another thread. If so, then step that thread past the breakpoint, and continue it. */ The variable thread_hop_needed determines if we should ignore the breakpoint hit and just move on (which I guess is what we want to do here). thread_hop_needed is set if: * there's a breakpoint at the current location, and it's set for another thread (not applicable in this case; the SIGTRAP comes from a now removed breakpoint) or * we're software single-stepping, and the stopped ptid doesn't match the single-step ptid (which is what saves CRIS, having software single-step). Obviously there is some logic missing to handle this case (using hardware single-step). I tried to add a third condition for setting thread_hop_needed, using currently_stepping (ecs) and !breakpoints_inserted, but that was too inclusive. Question is whether that is the right approach at all - after all, an i686-pc-linux-gnu host doesn't need it. > Is this native or remote (gdbserver based)? I have some patches which > make it substantially more reliable on slow native targets but I > haven't had enough time to test them properly. They shouldn't affect > remote though. This is a gdbserver based remote target. -- Orjan Friberg Axis Communications