From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120897 invoked by alias); 23 Jun 2015 04:07:57 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 120886 invoked by uid 89); 23 Jun 2015 04:07:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oi0-f43.google.com Received: from mail-oi0-f43.google.com (HELO mail-oi0-f43.google.com) (209.85.218.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 23 Jun 2015 04:07:55 +0000 Received: by oigx81 with SMTP id x81so136403089oig.1 for ; Mon, 22 Jun 2015 21:07:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bY7s8ai1WmUPpWu5yxEsfjEzWT4em2c/VaxDtpio9xk=; b=AZwAtuqQdCM0nof2ipTwtJabZZS/xzJ/zPQW0Vs9YOlAS92VX9IYZCCu+Iz0YxWdCt GqTtkrCmH+4EhvWA0AvjvT7A+zTirRmJn7YvKzlXcKdQCR0UiCNwTdS27AJN2AS0nUR1 1GDNx6nKWGa2O5XfL390a78FUVo1y3jknAO1BlxBf8/EBV7Ah22O2sWBNRZPy0qUgIpK 3AjLlN5220689N26GrikGBY083Y2NObTtJux427GTnJJEEOtqbXxt+hADvh5pZEsBprc MTsikdQTwud6gYAdThJZ8m7meuffuf5sjFOQUHGLrjkGEkqPOf5d7Z0EEO4M9AcLrSds kSzw== X-Gm-Message-State: ALoCoQmw171j8WleV8gsVJ2iejDlS3B3Xod2nOs3h9+bXD79LGX5HvNpQ5N4fOuxjXuSaewrbIS8 MIME-Version: 1.0 X-Received: by 10.182.71.72 with SMTP id s8mr12511939obu.80.1435032473130; Mon, 22 Jun 2015 21:07:53 -0700 (PDT) Received: by 10.182.89.99 with HTTP; Mon, 22 Jun 2015 21:07:52 -0700 (PDT) In-Reply-To: <557EF27E.3030900@redhat.com> References: <83h9tq3zu3.fsf@gnu.org> <55043A63.6020103@redhat.com> <8361a339xd.fsf@gnu.org> <5504555C.804@redhat.com> <550458E0.10206@redhat.com> <83y4jrsgui.fsf@gnu.org> <83ioaus6pt.fsf@gnu.org> <557ED083.1060804@redhat.com> <83si9tngaj.fsf@gnu.org> <557EF27E.3030900@redhat.com> Date: Tue, 23 Jun 2015 04:07:00 -0000 Message-ID: Subject: Re: Inadvertently run inferior threads From: Doug Evans To: Pedro Alves Cc: Eli Zaretskii , gdb Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00062.txt.bz2 On Mon, Jun 15, 2015 at 10:42 AM, Pedro Alves wrote: >... > With asynchronous control and background execution, you have to consider > what happens if the user does "info threads" just while GDB is handling > these internal stops. If the user does "step&" (step in the background, > and give me the prompt right away), and then does "info threads" while the > thread is busy doing the internal single-steps, it'd be highly > confusing to sometimes see the thread as stopped (e.g., if it needed to > be held a bit while another thread steps over a breakpoint) and sometimes > as running. I dunno if it'd be confusing. Maybe we could give up on trying to cover up the stopped/running state of the thread and just let info threads report something closer to what's actually going on? An asterisk or some such accompanying the output of threads in intermediate states may be a sufficient clue to the the user.