From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 4NeYHftsbWZoDjcAWB0awg (envelope-from ) for ; Sat, 15 Jun 2024 06:29:15 -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=YpM/qc23; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 741CB1E0CE; Sat, 15 Jun 2024 06:29:15 -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 5E35C1E030 for ; Sat, 15 Jun 2024 06:29:13 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B1C11388266B for ; Sat, 15 Jun 2024 10:29:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B1C11388266B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1718447352; bh=jweKjKt3YEGrHaMlk+7DE8zD1cm8WgkvdDnNEtin9aI=; h=To:Cc:Subject:In-Reply-To:References:Date:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=YpM/qc23hAoz1ZZZ38CunFLwfqJxiKm41RJX6yO2fJ4uM2eDLb1AyiVW6Fa6/m91+ VYVP6SRPHmvgln+HTdRPNSxFXlUPwhlZzuXHkGSjmUfUXdkWY/wzvpkXJ9qZndCmsM k5I/Q9mnaBRUrpkv9bbLMZ61EvZzt20pbZn4M04g= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 227C038708D1 for ; Sat, 15 Jun 2024 10:28:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 227C038708D1 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 227C038708D1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718447312; cv=none; b=kdq9SJaLGwL3NfrRcQE9PvHEj+N5PGy6MUv5NaZNmz8rx5ydWhq2G//Lfi+Oqq/c9i0k35i4xDsQlSF63yEOxfXpJ9Ew3cLh+cS4r3pGKwPUHmoZBZm20vxAnT/b4wlVNJHh8suBVeGTawJwjtvztM0VwumLzG+7p+ZQSodqu0s= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718447312; c=relaxed/simple; bh=vHYIzg+wbkEW/LMhD4UKDEvkVoyyXzqMBdATbhgKkPA=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=dTpXFa8AGpHbwVEWD7rI//VNoPHNMsCl6KAam/A9DKVJqC5y7/8k4MdozeOBe0Wk3y7rHhBwUTuz4UgCquegTNLH93QqVCyEiByzKmL88K4es+Uwp0+DUp0eJx9laNVTlyZmlr6DA88Be/htzdOL9eEmC8OBPBNyuz/gP7WLejU= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-624-WiLGCthRPeSwIaI-mEEbsQ-1; Sat, 15 Jun 2024 06:28:27 -0400 X-MC-Unique: WiLGCthRPeSwIaI-mEEbsQ-1 Received: by mail-ej1-f72.google.com with SMTP id a640c23a62f3a-a6f0fee1f49so164205066b.0 for ; Sat, 15 Jun 2024 03:28:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718447305; x=1719052105; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jweKjKt3YEGrHaMlk+7DE8zD1cm8WgkvdDnNEtin9aI=; b=Q3hh7YPamgHQnSfvN6R9b+kZ/a2ljXUWIOSrzr2Wdsm+E5xfgrycBSyQVpFDcn18mU emVh6rbQil6X6QN/5eQhm3na5RJN0ew+g79kzlc0gWMGsvGzRtauKFMTkYllhxh2Ab5f 7Y0ut6ZG6BSrM5UdDWqJk+mI57KsvYp9PXNTffdu6PdlFfqO8f5fUXnfW6JAgl335JEh hJNlj5K4l9Q0PpisdpH3vqdHj5cb3BmBdxsPi1HetyQxwxxfTFB3Qv18MpudBmRKbDQy wLppHJ7If8j9jUgucWq3jCZrguL3bW2n1jdkbZjtJI0gn58CwwvogicrRUGd6+jsC/YW NZhA== X-Forwarded-Encrypted: i=1; AJvYcCW9nciZ+j9C7IZjSifUSz+JPuT6E3G9dolhHC9hzkdDSgDEv0Ujv+sQ0BhmIMJMfbONEve0fvkEf7t+L5iol3518i8= X-Gm-Message-State: AOJu0Yz8/rGt+pWi0j6Dcff9UeDCmOcZN0v/vkeG7/hkHFGSKqgoNcR6 +qZQ9UL05zvj478kx8XS4d0JpNn0GnSnPI+HWA4zeKmU/xAauIoMzOFDum+cygjkPee2jouQcMY RAnEP2GKV3UQfXDwvwOtFdPBpn/lncgRnzY5PosPNe8SVr+vLkQtnQdg5 X-Received: by 2002:a17:906:36d7:b0:a6f:5e79:a0f2 with SMTP id a640c23a62f3a-a6f60dc1765mr302550766b.55.1718447305394; Sat, 15 Jun 2024 03:28:25 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEZzkREGH1z0FDCpUt7fSmrc9H9/PYXwmaMM4ayrlz7BT8YARKVNKRl3mr1UdRxy38nneS8gw== X-Received: by 2002:a17:906:36d7:b0:a6f:5e79:a0f2 with SMTP id a640c23a62f3a-a6f60dc1765mr302549766b.55.1718447304863; Sat, 15 Jun 2024 03:28:24 -0700 (PDT) Received: from localhost (92.40.185.178.threembb.co.uk. [92.40.185.178]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a6f56ecd5bfsm281854266b.113.2024.06.15.03.28.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Jun 2024 03:28:24 -0700 (PDT) To: Luis Machado , Simon Marchi , "Terekhov, Mikhail" , "gdb-patches@sourceware.org" , "gdb@sourceware.org" Cc: Pedro Alves Subject: Re: [RFC] Removing in process agent (IPA) In-Reply-To: <0be6727f-03c4-44cd-a9f2-3f05adc72b52@arm.com> References: <87y1797wqf.fsf@redhat.com> <87sexg7xqx.fsf@redhat.com> <0be6727f-03c4-44cd-a9f2-3f05adc72b52@arm.com> Date: Sat, 15 Jun 2024 11:28:23 +0100 Message-ID: <87plsi7b5k.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_ABUSEAT, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, RCVD_IN_SBL_CSS, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no 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: Andrew Burgess via Gdb Reply-To: Andrew Burgess Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" Luis Machado writes: > On 6/14/24 14:48, Simon Marchi wrote: >> >> >> 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). > > To be clear, I'm only proposing removing (1) at the moment. (2) might be worth > removing in the future if nobody is still using it (drops tracepoint support in > gdbserver). (3) is the more generic layer, and I suppose there are still a few > users out there. While there are users of (3) I would suggest we should keep (2) so that we (GDB project) can test (3). My initial question was only about (1), dropping IPA and everything that implies. Again, I have no strong feelings either way, I asked only because the idea was floated in some replies in other threads and I thought the question should be asked in its own thread. Thanks, Andrew