From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [209.51.188.92]) by sourceware.org (Postfix) with ESMTPS id AB4A1385695E for ; Tue, 21 Jun 2022 12:07:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AB4A1385695E Received: from fencepost.gnu.org ([2001:470:142:3::e]:43044) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3cfE-0005VL-4G; Tue, 21 Jun 2022 08:07:24 -0400 Received: from [87.69.77.57] (port=3925 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3cfD-0002s6-IU; Tue, 21 Jun 2022 08:07:23 -0400 Date: Tue, 21 Jun 2022 15:07:12 +0300 Message-Id: <838rpqkyof.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves Cc: gdb-patches@sourceware.org In-Reply-To: <20220620225419.382221-26-pedro@palves.net> (message from Pedro Alves on Mon, 20 Jun 2022 23:54:19 +0100) Subject: Re: [PATCH 25/25] Document remote clone events, and QThreadOptions packet References: <20220620225419.382221-1-pedro@palves.net> <20220620225419.382221-26-pedro@palves.net> X-Spam-Status: No, score=1.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2022 12:07:28 -0000 > From: Pedro Alves > Date: Mon, 20 Jun 2022 23:54:19 +0100 > > This commit documents in both manual and NEWS: > > - the new remote clone event stop reply, > - the new QThreadOptions packet and its current defined options, > - the associated "set/show remote thread-events-packet" command, > - and the associated QThreadOptions qSupported feature. Thanks. > ** GDBserver is now supported on LoongArch GNU/Linux. > > +* New remote packets > + > +clone stop reason > + Indicates that a clone system call was executed. I'm confused: what is the relation between the "stop reason" part and the description saying that "a clone system call was executed"? The gdb.texinfo description only mentions "clone" as the packet name, without the other 2 words. What am I missing? > +@cindex thread clone events, remote reply > +@anchor{thread clone event} > +@item clone > +The packet indicates that @code{clone} was called, and @var{r} is the > +thread ID of the new child thread. Refer to @ref{thread-id syntax} > +for the format of the @var{thread-id} field. This packet is only > +applicable to targets that support clone events. The text refers to @var{r} and @var{thread-id}, but they are not present on the @item line that describes the packet itself. Where are those parameters used in this case. > +@item QThreadOptions@r{[};@var{options}@r{[}:@var{thread-id}@r{]]}@dots{} > +@cindex thread options, remote request > +@cindex @samp{QThreadOptions} packet > + > +For each inferior thread, the rightmost options with a matching > +@var{thread-id} are applied. "Rightmost" means here "the last in the list"? If so, perhaps it's worth saying that explicitly to avoid possible confusion. > +@item > +Without clone events (on systems where threads are spawned via a clone > +system call), if the single-stepped thread spawns a new clone child > +(i.e., it executes a clone system call), and: > + > +@itemize @minus > +@item > +the breakpoint is stepped-over in-line, the spawned thread incorrectly > +runs free while the breakpoint being stepped over is not inserted, > +thus the spawned thread may potentially run past the breakpoint > +without stopping for it. By enabling @code{GDB_TO_CLONE}, the new > +cloned thread is halted before it executes any instruction; > + > +@item > +if alternativelly displaced (out-of-line) stepping is used, the > +spawned thread starts running at the out-of-line PC, leading to > +undefined behavior, usually crashes or data corruption. By enabling > +@code{GDB_TO_CLONE}, the new cloned thread is halted before it > +executes any instruction, and @value{GDBN} adjusts its PC before > +resuming its execution. > +@end itemize This reads awkwardly, because you say "and:", and start each @item of the following itemized list with a lower-case letter, but each @item includes more than one sentence. How about the following rephrasing: For example, @value{GDBN} enables the @code{GDB_TO_EXIT} and @code{GDB_TO_CLONE} options when single-stepping a thread past a breakpoint, for the following reasons: @itemize @bullet @item If the single-stepped thread exits (e.g., it executes a thread exit system call), enabling @code{GDB_TO_EXIT} prevents @value{GDBN} from waiting forever, not knowing that it should no longer expect a stop for that same thread, and blocking other threads from progressing. @item If the single-stepped thread spawns a new clone child (i.e., it executes a clone system call), enabling @code{GDB_TO_CLONE} halts the cloned thread before it executes any instructions, and thus prevents the following problematic situations: @itemize @minus @item if the breakpoint is stepped-over in-line, the spawned thread would incorrectly run free while the breakpoint being stepped over is not inserted, and thus the cloned thread may potentially run past the breakpoint without stopping for it; @item if displaced (out-of-line) stepping is used, the cloned thread starts running at the out-of-line PC, leading to undefined behavior, usually crashing or corrupting data. @end itemize @end itemize