From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id gU86I0svHmP8ZjcAWB0awg (envelope-from ) for ; Sun, 11 Sep 2022 14:56:11 -0400 Received: by simark.ca (Postfix, from userid 112) id 832591E22A; Sun, 11 Sep 2022 14:56:11 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=FbPOf5sR; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 1F7801E13B for ; Sun, 11 Sep 2022 14:56:11 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 24E9E385AC27 for ; Sun, 11 Sep 2022 18:56:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 24E9E385AC27 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1662922570; bh=3nsiSDmGwVBEY0Qh6woGCM6xUEqgHVLA+vex/+tSzl8=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=FbPOf5sRDK8jc/qb+tXUoBiwGTHO71ZjKtTmzsWRK0EPhOCXnd38P8edgoEncn7Ws AbfGFTajDHQhtcc+YTvW/nV4x5uMVtQz8Ov9+651Pnun46iIqmhao7G44cQPtX+8qP OJ9gLxghpRV2iW0i+DCPDwP7XJbhABWqtYwCJPvU= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id ECBF23858D32 for ; Sun, 11 Sep 2022 18:55:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ECBF23858D32 Received: from [10.0.0.11] (unknown [217.28.27.60]) (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 0B79D1E13B; Sun, 11 Sep 2022 14:55:41 -0400 (EDT) Message-ID: Date: Sun, 11 Sep 2022 14:55:40 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.0 Subject: Re: Issues With Thread Events In User Mode GDBServer Content-Language: en-US To: Bill Messmer , "gdb@sourceware.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: , From: Simon Marchi via Gdb Reply-To: Simon Marchi Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 2022-09-09 16:04, Bill Messmer via Gdb wrote: > Folks, > > Apologies if this is the wrong mailing list to ask a question regarding GDBServer / RSP and a potential bug. > > I have been working on new extensibility API surfaces for the Windows platform debuggers that allow folks to write plug-ins that can connect those debugging tools to a variety of new targets including ones that are not Windows based. We've had the ability to do this for post-mortem targets for some time and are, of late, working to expand that API surface to various forms of live targets. > > As proof of concept for the API surface, I've been experimenting with writing such a plug-in to connect to the standard user mode GDBServer for Linux. A few things I'll note: > > > 1. When thread events are enabled on the server via a QThreadEvents:1, GDBServer immediately crashes on any thread exit in "resume" on a NULL deref of current_thread. > > > > 1. I tried a quick patch here (adding "cs.last_status.kind() != TARGET_WAITKIND_THREAD_EXITED") to the set of conditions that won't set "current_thread->last_status" and the wXXX thread exit packets get sent; however, regardless of whether the target is in non-stop mode or not, the process is STILL RUNNING at the time the server sends the "wXXX" packet. > > > Am I missing something with GDBServer and thread events or is this just not well supported...? The process seems to be stopped at the point that a thread creation event gets sent... but not for a thread exit... I assume that's a bug somewhere in GDBServer...? Or am I misreading the docs at https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html...? Is there some alternate means by which thread create/exit notifications come...? > > Sincerely, > > Bill Messmer > wmessmer@microsoft.com Hi Bill, I don't quite understand the situation you are describing. Can you maybe send a log of the communication between your tool and GDBserver? Simon