From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id wPoGDGxKbGaekzUAWB0awg (envelope-from ) for ; Fri, 14 Jun 2024 09:49:32 -0400 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=op2x+Pwg; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 2DE0A1E0C1; Fri, 14 Jun 2024 09:49:32 -0400 (EDT) Received: from server2.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 ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 19AB11E030 for ; Fri, 14 Jun 2024 09:49:30 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AFE4D388211C for ; Fri, 14 Jun 2024 13:49:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AFE4D388211C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1718372969; bh=g95gWslAn8gEqSx5r9cjYulN04uZxzvVVD/2NvnHVPU=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=op2x+Pwg2ToPy2UUwKqhXbdlH/iXS0o1+9oicI1UvLjsPkD73jDKDQjCxzxk5Pvre /wO8eM+fEgM/3wxbjBIXv76SpDmmfBSZrZk7Q+D9P0HFxYWurwgY74zAkY9O3YGGGT xv2/Qu1F8/kQbs2G+JAQrxjV6RWsA6upcc3U4988= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 3395F3882168; Fri, 14 Jun 2024 13:48:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3395F3882168 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3395F3882168 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718372928; cv=none; b=mHkAr8i8Ajs3FMlYixQcA8Acu79VdTvSCfBBRK5A83iJvntkl6WJ2R0M/kNS3LfDAxMnhA2cXkzQx8iuZDvleCkQ9RFA8NE0riHX/ETrQu7yCJvQUz+znItehMN4XtvGr6Y3M6pZU75Zj9YPImR5trulNAMwTX08VAKuVp2eYAY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718372928; c=relaxed/simple; bh=54WmPM8SnvALgtHLBOSL6lcMuCDVdD4XlAWP2KHnkNI=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=qF25cjipQdX5ORQxJlrrqOBqKt3VVKFDDDwNmym0LBh4XEtAP8mjahyu9MV5ihek5WjHUt0k1qgJYQK3FJn5RnY88+ezlfsjjq7SBOdt8ZcoiAKQlCnsNEoahXbobFPlwdKpwcCWJCK5+t2ENQTi2mGV3oNSb6d6d+jbf7Ta/cc= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [10.0.0.11] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id B03BA1E030; Fri, 14 Jun 2024 09:48:45 -0400 (EDT) Message-ID: Date: Fri, 14 Jun 2024 09:48:45 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] Removing in process agent (IPA) To: Andrew Burgess , "Terekhov, Mikhail" , Luis Machado , "gdb-patches@sourceware.org" , "gdb@sourceware.org" Cc: Pedro Alves References: <87y1797wqf.fsf@redhat.com> <87sexg7xqx.fsf@redhat.com> Content-Language: en-US In-Reply-To: <87sexg7xqx.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 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 2024-06-14 04:08, Andrew Burgess wrote: > "Terekhov, Mikhail" writes: > >>> -----Original Message----- >>> From: Luis Machado >>> >>> Similarly, I also think it might be time to consider dropping the tracepoints >>> (mainly static and fast) machinery from gdbserver, as I suspect that is another >>> mechanism that is not being used very often. >>> >> We use tracepoints in our stub from the last millennia I guess (back from EMC days) >> and plan to do so in the future. >> >>> I recall trying to use tracepoints for practical purposes (back in the day), and it >>> wasn't up to the task, being too cumbersome to use, having bad failure modes >> >> Putting some UI/GUI on top of it makes it relatively simple to use. >> >>> and having other security implications when trying to debug stuff in >>> production platforms. The remote protocol side of it is OK, but again, I bet no >>> debugging stubs are using that anymore. >> >> We do use them but not in production though. > > Just so I'm clear, you're talking about tracepoints here either in > gdbserver, or at least (if you have your own stub) in GDB and the remote > protocol, right? > > This doesn't require gdb to continue shipping the IPA right? Or have I > failed to understand your position? Just to clarify one thing: the IPA is only needed for the fast tracepoints mechanism, which allows recording trace data all in process, without hitting a trap and the control going back to GDBserver. We can still use regular trap-based tracepoints without the IPA. The possible levels of removal are: 1. Remove the IPA, thus removing the support for fast tracepoints in GDBserver (you could still use regular trap-based tracepoints) 2. Remove the support for tracepoints in GDBserver altogether (you could still use the tracepoints feature in GDB, when connecting to another RSP implementation than GDBserver, although the tracepoints feature in GDB would become untested code) 3. Remove the support for tracepoints in GDB and GDBserver completely (which I would not consider since Mikhail says they use that). Simon