From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 02DB33858D39 for ; Thu, 3 Mar 2022 15:44:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 02DB33858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [172.16.0.95] (192-222-180-24.qc.cable.ebox.net [192.222.180.24]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 1D8C71F0D2; Thu, 3 Mar 2022 10:44:25 -0500 (EST) Message-ID: Date: Thu, 3 Mar 2022 10:44:24 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: GDB/MI - Possible missing stop-reason on attach or misleading documentation Content-Language: tl To: Simon Sobisch , gdb discussion list References: <8a90c905-f238-0e14-ef7b-21c0eac58948@gnu.org> From: Simon Marchi In-Reply-To: <8a90c905-f238-0e14-ef7b-21c0eac58948@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3639.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2022 15:44:27 -0000 On 2022-03-03 03:35, Simon Sobisch via Gdb wrote: > When attaching to a running progress (that currently "waits" in `getchar()`, but that likely doesn't matter) in async mode the following records are returned: > > =thread-group-started,id="i1",pid="12345" > =thread-created,id="1",group-id="i1" > =library-loaded,id=... many entries > ~"0x00007fa0a626b7e0 in __read_nocancel () from /usr/lib64/libc.so.6\n" > *stopped,frame={addr="0x00007fa0a626b7e0",func="__read_nocancel",args=[],from="/usr/lib64/libc.so.6",arch="i386:x86-64"},thread-id="1",stopped-threads="all",core="1" > > My understanding from > https://sourceware.org/gdb//onlinedocs/gdb/GDB_002fMI-Async-Records.html was that the reason field is _always_ returned. > > Questions: > * Did I look at the right place of the docs? I think so. > * Are all fields listed there should always be filled? If it doesn't say otherwise, yes. This looks like a bug. > If not I highly suggest to add a note about that. > * Can the reason field be added in the attach case? I _guess_ that would > be either "location-reached" or "breakpoint-hit". Or signal-received, same as you get when GDB interrupts a running thread after the user does ^C. It depends on the status the target returns. Attaching is kind of like the user requesting the attached process to stop. Simon