From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2371 invoked by alias); 21 Nov 2014 10:43:13 -0000 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 Received: (qmail 2357 invoked by uid 89); 21 Nov 2014 10:43:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 21 Nov 2014 10:43:11 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sALAh8td029125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 21 Nov 2014 05:43:08 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sALAh64Y013237; Fri, 21 Nov 2014 05:43:07 -0500 Message-ID: <546F173A.3070204@redhat.com> Date: Fri, 21 Nov 2014 10:43:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Joel Brobecker CC: gdb-patches@sourceware.org Subject: Re: RFC: skip_inline_frames failed assertion resuming from breakpoint on LynxOS References: <20141120051109.GR5774@adacore.com> <20141120051223.GA23720@adacore.com> <546DBA9F.9060600@redhat.com> <20141120171137.GT5774@adacore.com> In-Reply-To: <20141120171137.GT5774@adacore.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-11/txt/msg00505.txt.bz2 On 11/20/2014 05:11 PM, Joel Brobecker wrote: > Hi Pedro, > >>> infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT, step=0) >>> infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [Thread 142] at 0x10684838 >> >> trap_expected=1 indicates that GDB is about to step thread 142 _only_, leaving >> everything else stopped. Can you enable "set debug remote 1" as well? > > Correct (we are single-stepping out of a breakpoint). > > Here is the output with remote debugging: > | Sending packet: $vCont;s:8e#8f...infrun: wait_for_inferior () Alright, GDB really did resume only thread 0x8e/142. >> So how come we see an event for thread 146? That thread shouldn't >> have been resumed, so GDB shouldn't be getting an event for it. >> >> This is sounding like a bug in the target. > > I thought about this too, and there might be a ptrace request > I can use to absolutely limit the resumption to the one thread. > I say "might" because only testing will show if the request is > supported, and works, on all versions of LynxOS. I had a feeling we had discussed this before... See: https://sourceware.org/ml/gdb-patches/2013-05/msg00436.html The (very) old gdb/lynx-nat.c code in GDB used to do this, so it should work. Could you try it? We're going to be keep hitting all sorts of issues until this is finally done. > > But I have always been relunctant to do so for 2 reasons [1]: > - It affects the program's scheduling; That's hardly an issue, when the program had just completely stopped for a breakpoint. :-) > - Can the program lock up if we're trying to single-step > a thread that's blocked? The thread just hit a breakpoint, so it was not blocked in sense of the kernel not allowing its scheduling before. The main issue is that we're trying to move the thread past a breakpoint. Barring displaced stepping support, to move the thread past the breakpoint, we have to remove the breakpoint from the target temporarily. But then we _cannot_ resume other threads but the one that is stopped at the breakpoint, because then those other threads could fly by the removed breakpoint and miss it. Regarding lock up, the only issue I see is if the instruction the breakpoint was put on is a syscall instruction that calls into the kernel and that could block. That's a corner case that we e.g., never found the need to handle on Linux. syscalls tend to wrapped in libc functions, so users don't normally put breakpoints on syscall instructions. But still, there would be ways to handle it. E.g., when stepping, ask the kernel to report syscall entry, and if a syscall entry is detected, we know the instruction has executed, so we can reinsert breakpoints, and resume execution of all threads again. Similarly to how we always want to be notified of signals when we step. (From infrun.c: "If we have removed breakpoints because we are stepping over one (in any thread), we need to receive all signals to avoid accidentally skipping a breakpoint during execution of a signal handler.") > Also, what made me consider this change independently of the questions > above is that it seems to me that it the situation we are facing here > seems to be easily handled. So, to avoid headaches from other "buggy" > targets, containing this situation seemed friendlier. Don't we also > have other targets that don't have the capability to resume one single > thread? I honestly hope not. Resuming only a particular thread is a very basic debug API feature. Thanks, Pedro Alves