From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 8QAmMsM2iWcfSBEAWB0awg (envelope-from ) for ; Thu, 16 Jan 2025 11:41:39 -0500 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=Zi64bk70; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id BD8451E100; Thu, 16 Jan 2025 11:41:39 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.0 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 11FBA1E05C for ; Thu, 16 Jan 2025 11:41:39 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A77A0384DED2 for ; Thu, 16 Jan 2025 16:41:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A77A0384DED2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1737045698; bh=7e7WFDtCaoob5/1gsMyce6v4ZlR/CgRRR96ucROnKM4=; 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=Zi64bk704TG9Bv2GmAXJa3w0zq2n9MhP/xErf5HnLUuS5xg622+JRiYMF64AOzwgc gjoxY2WZOD0WW2KZKBbDQcGgisWj0wKljhQyZNtURDJoqlCdemSVSMoBxd/j2+vcjP ao0QkMrtiJoKyp0b6HIaYt2tH9Vw5JVffWNr8v08= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id B9AC0384DEE8 for ; Thu, 16 Jan 2025 16:40:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B9AC0384DEE8 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B9AC0384DEE8 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1737045650; cv=none; b=oxr8sJDJBrcHYjy8NCP7GlfhKcb3JOckjD5+q46ZyMnCJdzmmbQ+NcxdNmk/LsSjBarwk9X/460ZxT1H/l7eCcRCvFbxrsBn5bKEa2xuXVZ8+nPajOeNYmXfG3+TBkKLthIR7zCeYB3vanRFJY2pByvFUKLJNOtV4KAffnXN278= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1737045650; c=relaxed/simple; bh=SSSuxC3YLh50xZfcrNsFBkw93hx1rMLp8pP1TF7Jxgg=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=vHxOIivpB0O8bR9imz8ahE6cya06b1NaZ9bO6+KX9H7JuRt7DoRBaIkiZVoWGWeb7e2JrZUyI/L/2PvgraJ/B2BLgXR/QIAqTjlEtTJCnnqYqwlEQWHMjz4H5EkYlZwyOBnd5hEMHMkN7ntKQHkjhOdXHkBOmiNG2N69IydDKiM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B9AC0384DEE8 Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-541-_gT4jlcbPnyBlxo_ta7l4w-1; Thu, 16 Jan 2025 11:40:49 -0500 X-MC-Unique: _gT4jlcbPnyBlxo_ta7l4w-1 X-Mimecast-MFC-AGG-ID: _gT4jlcbPnyBlxo_ta7l4w Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-3862a49fbdaso504892f8f.1 for ; Thu, 16 Jan 2025 08:40:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737045648; x=1737650448; 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=7e7WFDtCaoob5/1gsMyce6v4ZlR/CgRRR96ucROnKM4=; b=Jyf+/Wx442x7PpO2M0CZieN2PE4g+G6lNLANKgbLRMnDrf7y9Yhy5AsGVKQwhi5BAu BqgImBUb4jtxqnqY6Qqnx8Y4Uvy1IBGytNA0WGEoBWthdU0onZLhI+ik9z9sDM4ngdm7 xJ5qmSKKwN2y44585guZrmjWfbrIFDPS1IREXJGXe45I1clRz8BD5+k+5sVBz+jTSph0 mpYOXbvpY0SFz4c6ADj/20Roi4TVqKikZbcrCFK4JTRr++0U4BX+WFdPUIO0uOdLUUz4 hKP5l8BhF2NYyBVSIMP/KcNqXhAIyjB1nXSFmflntQnRY9KOaW+AyEGwTTT63/ERDMhs PYMQ== X-Forwarded-Encrypted: i=1; AJvYcCWJkrjz4zCe1pOI3+lnYpoSomBNmLIcw+Y6NnxCGNSq3AQIoWoxVk3RaauUz3PXyLfiQ68=@sourceware.org X-Gm-Message-State: AOJu0YzKGVGPuR7f0N8xvAWctwi9eZ5JOwmxKg0CJ1Yz242DEjhJ4F5T E8kGZzIb8opBxVxwejEfU6hZtfd0lNr+t/YgCcCza9yjYzho2D9SwItEfqKCrm3DD5oYurbaINV 7FlRRz6AND2IqB1sXVox6U0xFJmiFV3DGXKJ1E/4k1vANCtRQ X-Gm-Gg: ASbGncsR5KVfUZJ2MzMGqRk0VWfVHuEqqt1X4yNekcd4B+5k9EP+JkFkxBAhv4gd/j7 rGBIPybfLcLc9UsMjhGUG+JCUoJV/7Sy0qEb2S5Dw4bZu6iAPVXxYb2ht7TWKX9mG0f8NazcMk9 V4L8U4cq/N08DlKENcJ7KvFZJRRLJaihDBQ2APrCedMd+50eD86cDFUFY5jWO2JF3D2G/4Lw4SM o4g26/vtXfVPF1wBcYCZA7LODtFA7pG1c0ggE1vP36AVpd/NmI6lfORYACcNAawp2U3BvFjwXLi xuhPGw== X-Received: by 2002:a5d:598b:0:b0:385:ee40:2d75 with SMTP id ffacd0b85a97d-38a872da8b6mr26335623f8f.20.1737045648161; Thu, 16 Jan 2025 08:40:48 -0800 (PST) X-Google-Smtp-Source: AGHT+IEsPQ0qJgMaj7xoIyVDYJ8PWqzqvOhBgJZCXLSv7qGNtpsUkcjg1n2xBjj0vfYvDwPA9u2zaw== X-Received: by 2002:a5d:598b:0:b0:385:ee40:2d75 with SMTP id ffacd0b85a97d-38a872da8b6mr26335602f8f.20.1737045647773; Thu, 16 Jan 2025 08:40:47 -0800 (PST) Received: from localhost (44.226.159.143.dyn.plus.net. [143.159.226.44]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38bf32755f0sm282966f8f.76.2025.01.16.08.40.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jan 2025 08:40:47 -0800 (PST) To: Luis Machado , Stephen Brennan , Tom Tromey , Luis Machado via Gdb Cc: linux-debuggers@vger.kernel.org, Omar Sandoval , Amal Raj T Subject: Re: GDB Remote Protocol Extension - Linux VMCOREINFO - Request for Feedback In-Reply-To: References: <8734hmtfbr.fsf@oracle.com> <5e1c692b-b103-4c47-8cc3-d8ce487d98e1@arm.com> <87plkpqpuj.fsf@tromey.com> <87y0zds39y.fsf@oracle.com> <87cygnoxi2.fsf@redhat.com> Date: Thu, 16 Jan 2025 16:40:46 +0000 Message-ID: <87y0zaogoh.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: O0AYNLAacdNWP86RBqBgkSkSyK5fwGwfwl25XctujxM_1737045648 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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 1/16/25 10:37, Andrew Burgess wrote: >> Stephen Brennan via Gdb writes: >> >>> Tom Tromey writes: >>>>>>>>> Luis Machado via Gdb writes: >>>> >>>>>> To sum up, my specific questions are: >>>>>> >>>>>> 1. What is the maximum protocol packet size, if any? >>>> >>>>> It is hardcoded by gdb, but the remote can also specify that, but... >>>> >>>>>> 2. Would this functionality be better implemented in a single "q >>>>>> linux.vmcoreinfo" packet, or as a "qXfer" packet? >>>> >>>>> ... we have packets like qXfer that can handle multi-part transfers. So the >>>>> packet size is not a critical concern anymore, and it is best to use this >>>>> newer mechanism, if the usage fits the packet structure. >>>> >>>> Agreed, qXfer is the way to go. >>> >>> Thank you Tom & Luis for confirmation, qXfer seems appropriate. With >>> that approach the buffer size is not really a concern: we can simply use >>> the minimum of the requested read size, and the stub's buffer size. So >>> long as clients use multiple requests until the data is fully read. >>> >>> While the "os" object also sounds like a good place to put this (e.g. >>> within a new annex), it seems like that contains XML-formatted data with >>> well-understood schema and semantics. The vmcoreinfo is free-form text >>> (generally of a "key=value" format), so it probably should be a separate >>> object. >>> >>> So I think we would prefer to add an object type, e.g. named "vmcoreinfo". >>> (But please do speak up if this sounds like a mistake) >>> >>>> If you're adding a new object type, a patch to the manual would be good. >>> >>> I'll definitely include a patch for the manual in the plan for this. >>> Another patch I'd like to write is to allow GDB's server to expose this >>> object type when the target is an ELF core dump with a VMCOREINFO note. >>> We're hoping for this to useful for all debuggers, not just drgn. >> >> Hi Stephen, >> >> I took a look at the wiki page and it seems like initially at least, >> your plan is to make the information from vmcoreinfo available via a new >> 'info' command. >> >> It is possible to send remote packets through GDB's Python API[1]. And >> of course, the Python API allows for new commands to be created[2]. >> There is a test in GDB's test suite that makes use of the packet sending >> API, and it happens to send a qXfer packet[3]. >> >> I say all this not to put you off contributing a patch to core GDB, but >> if what you want is a new user command which will send a packet to a >> remote target and process the results, then it should be possible to >> implement this as a Python extension. > > A bit off-topic, but wouldn't that have the potential to proliferate > remote packets gdb/debugging stubs have no control over or no documentation > to point at/refer to? Possibly contributing to greater confusion as to what > should be minimally supported in terms of remote packets? I don't see a problem, but that doesn't mean using an extension is the right choice in all cases. Using an extension, in my mind, ties the functionality to the project. So if we expect many remote targets to support the new packet then it begins to make more sense to move the functionality into the GDB tree (maybe as C++ code, or maybe as Python code). But if, really, the new feature only applies for one project, then it makes more sense (for me) to add GDB support via an project specific extension. Documentation would naturally live within the project itself. On the topic of control, I'm not entirely sure what problems you see. Using a project specific extension gives (IMHO) the project more control over the packet as they are free to change the packet over time. Currently GDB is pretty conservative with changing packets, so if a single project pushed their own custom packet to GDB core, and then wanted to change the packet, there's a risk we (GDB team) might refuse the change "just in case" someone else has since started to use the packet. That might be seen as the project having less control. Looking at GDB's control over packets, I'm not sure what control GDB needs. For sure, there's a risk that if extensions start creating their own packets then there is a risk that GDB might later add a conflicting packet, which could be a problem, and one reason we might want to move from an extension to a core packet. I doubt, right now, there are many "custom packets" in the wild, but maybe we should consider defining namespaces for custom packets, to avoid future conflicts? The minimally supported problem is usually about the minimal set of packets that a remote target needs to support, rather than the set GDB supports. In most cases, communication is initiated by GDB, so if GDB isn't aware of this packet (extension not loaded), GDB will just never ask for it. I'm certainly not making the argument that using an extension is the right choice in every case. Not every packet type is going to be right for implementing as an extension. Additionally, it might be that a project starts with an extension while prototyping a new packet, and then ports it to C++ and contributes it to GDB later once the design is solid. I've had success using packets via Python before, and not everyone is aware this feature is available, so I thought I'd mention it. Thanks, Andrew