From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66100 invoked by alias); 5 Nov 2019 14:06:37 -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 66090 invoked by uid 89); 5 Nov 2019 14:06:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_2 autolearn=ham version=3.3.1 spammy=robert, Robert, Starting, HTo:U*bob X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-2.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (207.211.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 05 Nov 2019 14:06:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1572962794; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uVbWuV1O7dwd63/gHDskLt8MkLwDY3qWK9mb8Oy+8oA=; b=g1WCkw5FiSQqvRWTW7MOcg1PuOXFZEsDUEiHn2GGu433uUxDmz7K83loziO2tj+RWM4qVA v/E4Nhp38+kjGmB9ZakwlFw6NPm2D1zPJ8/ei+9L0wLYw90H6Mi9au1vc9r1dIpbtu9r8W /Q0Y0hLVVRJdpjj2T4qdiFIcTX474XQ= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-377-afn1gOqKMQa_GMm9amXsjw-1; Tue, 05 Nov 2019 09:06:33 -0500 Received: by mail-wr1-f69.google.com with SMTP id u2so6279947wrm.7 for ; Tue, 05 Nov 2019 06:06:32 -0800 (PST) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id g184sm25745106wma.8.2019.11.05.06.06.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Nov 2019 06:06:31 -0800 (PST) Subject: Re: gdb/mi, new-ui. the console and determining when GDB is ready for the next command To: Robert Rossi References: <12814f17-0c65-e214-7e68-3214d3ed6ab6@redhat.com> Cc: GDB Development From: Pedro Alves Message-ID: Date: Tue, 05 Nov 2019 14:06:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2019-11/txt/msg00015.txt.bz2 On 11/2/19 10:35 AM, Robert Rossi wrote: > Huh. Here is my setup. >=20 > $ gdb --version > GNU gdb (GDB) 8.3.1 >=20 > On terminal one with gdb I have, > $ gdb -q -ex "new-ui mi /dev/pts/11" ./test_main > Reading symbols from ./test_main... > New UI allocated > (gdb) > Terminal 2 shows > $ tty > /dev/pts/13 > $ sleep 1000 > =3Dthread-group-added,id=3D"i1" > (gdb) <--- Good >=20 > So far everything is good. Now in terminal one I make a breakpoint. >=20 > Terminal 1 shows > (gdb) b main > Breakpoint 1 at 0x4006c0: file test.cpp, line 42. > (gdb) > Terminal 2 shows > (gdb) >=20 > =3Dbreakpoint-created,bkpt=3D{number=3D"1",type=3D"breakpoint",...,origin= al-location=3D"main"} > <--- No GDB prompt >=20 > However it has no gdb prompt. A gdb prompt indicates that GDB is ready to accept commands again. Here you have an asynchronous notification, which can appear at any time. GDB never stopped accepting commands since that initial prompt. So no new prompt. > Now, if I run the program, >=20 > Terminal 1 shows, > (gdb) r > Starting program:.../test_main >=20 > Breakpoint 1, main (argc=3D1, argv=3D0x7fffffffdea8) at test.cpp:42 > 42 { > (gdb) > Terminal 2 shows > =3Dthread-group-started,id=3D"i1",pid=3D"25913" > =3Dthread-created,id=3D"1",group-id=3D"i1" > =3Dlibrary-loaded,id=3D... > =3Dlibrary-loaded,id=3D"/lib/x86_6.... > ~"\n" > ~"Breakpoint 1, main (argc=3D1, argv=3D0x7fffffffdea8) at test.cpp:42\n" > ~"42\t{\n" > *stopped,reason=3D"breakpoint-hit",...stopped-threads=3D"all",core=3D"0" > <-- No GDB prompt >=20 > In this case also there is no gdb prompt. Same thing here. These are all asynchronous notifications. GDB is accepting MI commands before and after all these notifications, even if the CLI channel isn't. E.g., if you run a program that doesn't hit a breakpoint, you'll get on the CLI: (gdb) r Starting program: /tmp/infinite-loop iter 1 iter 2 iter 3 iter 4 ... while on the MI channel you get: ... *running,thread-id=3D"all" and you can still issue commands there, while the program is running: -data-evaluate-expression 1 ^done,value=3D"1" (gdb)=20 >=20 > Is this expected behavior or an oversight? >=20 It's expected. Thanks, Pedro Alves