From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13215 invoked by alias); 10 Feb 2017 19:20:12 -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 13205 invoked by uid 89); 10 Feb 2017 19:20:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=giant, nurses, locks, gil 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 ESMTP; Fri, 10 Feb 2017 19:20:02 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2EB64C05AA59; Fri, 10 Feb 2017 19:20:02 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1AJK0WN012691; Fri, 10 Feb 2017 14:20:01 -0500 Subject: Re: [PATCH] Don't send queries to the MI interpreter To: Simon Marchi , Simon Marchi References: <20170210163650.10334-1-simon.marchi@ericsson.com> <89904751-7015-b272-98c1-33e786f7c356@redhat.com> <85ae4ad9-acdc-c9ba-6606-a7ac2abc7e2e@redhat.com> <0d8bd42f-5964-1ac7-414a-754540db2e95@redhat.com> <71cf7c59-8b3c-595d-b4ec-69f44ae3d6fc@ericsson.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <9751aea3-0481-4c4b-52e5-3dcccbf89bad@redhat.com> Date: Fri, 10 Feb 2017 19:20:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <71cf7c59-8b3c-595d-b4ec-69f44ae3d6fc@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-02/txt/msg00277.txt.bz2 On 02/10/2017 07:05 PM, Simon Marchi wrote: > On 17-02-10 01:07 PM, Pedro Alves wrote: >> So I think that to support multiple queries like that >> the simplest / most natural would be to make each >> UI above run on its own thread, so that each would have >> its own independent stack/frames. > > Indeed. That represents a tremendous amount of work I imagine, > putting the proper locking mechanisms in place... And if you > are holding a lock while the query is issued, it would still > block some other things. I had it working with a GIL/BKL-style lock, in the original "new-console" prototype that was later rewritten into what is "new-ui" today. I.e,. even though we'd have multiple threads, only one thread really runs at a time. The idea was that we'd start with a big lock, and then over time break down the lock into more finer-grained locks. Here: https://github.com/palves/gdb/commits/palves/console-extra - A thread per UI. See the "Start a thread for each UI" patch. - Per-UI readline (with a giant readline hack) - Per-UI nurses/TUI instance (it really works!) :-) The trouble is that this then trips on another nasty problem: All ptrace calls targeting a process must be issued from the thread that first attached to that inferior process. The kernel rejects the ptrace call otherwise eith EIO/EINVAL or some such, I don't recall which. So on that branch, with native debugging, if you start the inferior on UI #1, and then try to read memory from UI #2, it fails... If you instead try the same against gdbserver, it all works, because in that case gdbserver handles the ptrace calls, not gdb, so all ptrace calls come from the same thread in that case. So for native debugging, we'd need to marshall all ptrace requests through the same thread... Thanks, Pedro Alves