From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id uhFRAIwLmGdLlRwAWB0awg (envelope-from ) for ; Mon, 27 Jan 2025 17:41:16 -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=OmZ6M1Lf; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id E68EB1E105; Mon, 27 Jan 2025 17:41:15 -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 962E51E05C for ; Mon, 27 Jan 2025 17:41:14 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 256123857C5F for ; Mon, 27 Jan 2025 22:41:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 256123857C5F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1738017674; bh=xnLZOvKqBIZzzTWyACTunpQIISPvc7l5tBWc2/t3cHk=; h=Date:To:Cc:Subject:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=OmZ6M1LfFrtnoOoV/QqEJG7LIRduZ1FDxH8F6SpMlmcZLc7RfnKrgdYNHEOQmV/Cv irtQJ33Nr6/xadVbErhR6iW51oW8u1yyTftA3grHR8KUxentLdsWsMQkHkyt84xVSc YEPSAdQu4VMK8b2ShTS21f96PrnGEUwkqnL9Xe1Q= Received: from todd.t-8ch.de (todd.t-8ch.de [IPv6:2a01:4f8:c010:41de::1]) by sourceware.org (Postfix) with ESMTPS id 031263858C5F for ; Mon, 27 Jan 2025 22:40:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 031263858C5F ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 031263858C5F ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1738017624; cv=none; b=WieLU0cfr4iu1ANdekGFiwBx2E1+UB0/MmeN7DQUhWZdMLAG5ST1FWD0gHjC0M4jKrdoHyngfnr28ufudMuew9QucwXtL620JfEO92IBseHxHE7sihyLHRGXQjbwHX6aK9SUjlOmzVkd270fxmyUi8pIGFO/ebg/geM1XiFLPKo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1738017624; c=relaxed/simple; bh=q5rccZbcmC2FCSOyuXRvQ70YHSzmVxugvvcJuj2KlRI=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=FXtf/6W3z+e/M35yRuHXjKr9rQu7uVQ7OOPWAqe5jRjSmw1GkjnKUEhXInD4kbEaYmFieCaY3i217L3+9B0v9/TRQglb31me5N+sU/E539H/e5nFIMtR0e0Y6Kx7eEzm9D+Oz3OaWdQO4UhMC+3x44qMorbbaodwZBgVfgkZ1iA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 031263858C5F Date: Mon, 27 Jan 2025 23:40:21 +0100 To: Stephen Brennan Cc: Omar Sandoval , gdb@sourceware.org, linux-debuggers@vger.kernel.org, Amal Raj T Subject: Re: GDB Remote Protocol Extension - Linux VMCOREINFO - Request for Feedback Message-ID: <3a0f50f6-3d03-4109-b0a8-0b743559356c@t-8ch.de> References: <8734hmtfbr.fsf@oracle.com> <766010fa-49a5-4e86-a730-bf79bb73e928@t-8ch.de> <87y0ywgkss.fsf@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87y0ywgkss.fsf@oracle.com> 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: =?utf-8?q?Thomas_Wei=C3=9Fschuh_via_Gdb?= Reply-To: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 2025-01-27 10:42:59-0800, Stephen Brennan wrote: > Omar Sandoval writes: > > On Sun, Jan 26, 2025 at 07:07:47PM +0100, Thomas Weißschuh wrote: > >> On 2025-01-13 16:22:00-0800, Stephen Brennan wrote: > >> Do you need to transfer the full vmcoreinfo data? > >> Wouldn't it be sufficient to only include the address/size of the > >> vmcoreinfo note in memory and the debugger can read the data from there > >> with regular memory access commands? > >> That information is enough for QEMUs vmcoreinfo device. > >> It would simplify the design and implementation(s) significantly. > > I do agree that this would simplify the protocol design, and it's a good > idea I hadn't considered. Thank you! > > > Oh, that's a good idea. I guess the downside is an extra command round > > trip. > > > > QEMU and KGDB also only implement the `m` command for reading > > hex-encoded memory. We'd probably want to implement the `x` command for > > both since it doesn't (usually) double the transfer size. > > > > One more caveat is that KGDB doesn't check the length passed to the `m` > > command and will happily clobber memory... QEMU's gdbstub does seem to > > check, and also advertises its packet size, so we probably want that in > > KGDB, too. > > > > Stephen, what do you think? > > One of our core constraints is that the vmcoreinfo is quite a bit of > text data, around 3k bytes right now. Doubling that to 6k would be a > real problem, so it would be really helpful to keep this to using the > 'x' encoding. However, I think there's a couple good reasons that > neither QEMU nor KGDB support the 'x' packet: Could you elaborate why it "would be a real problem"? If it is a problem with static buffer sizes, wouldn't this be avoided by configuring a max packet size? The debugger would have to request the data in chunks. This is also what the drgn pull request currently does for all memory reads. Without knowing much about drgn, I would have expected the regular memory accesses to be much more data then the 3KB vmcore notes. > 1. You cannot know the required buffer size easily, so you cannot know > whether you will be able to satisfy an 'x' request in your static buffer > size. This is most relevant to kgdb. The 'x' packet documentation says: > > The reply may contain fewer addressable memory units than requested if > the server was reading from a trace frame memory and was able to read > only part of the region of memory. > > I'm not certain what trace frame memory is, but the vmcoreinfo is not > that. I'm not confident whether this means the protocol allows fewer > bytes to be returned for other cases? Certainly, the 'qXfer' packets > explicitly allow for fewer bytes to be returned, as the documentation > states: > > It is possible for data to have fewer bytes than the length in the > request. If I understand correctly "trace frame" refers to same sort of cache. It's not a property of the target memory but how it is managed by gdb. For m reads, gdb itself explictly seems to allow short reads, also referring (not exclusively) to trace frames. Server: /* Read trace frame or inferior memory. Returns the number of bytes actually read, zero when no further transfer is possible, and -1 on error. Return of a positive value smaller than LEN does not indicate there's no more to be read, only the end of the transfer. E.g., when GDB reads memory from a traceframe, a first request may be served from a memory block that does not cover the whole request length. A following request gets the rest served from either another block (of the same traceframe) or from the read-only regions. */ static int gdb_read_memory (CORE_ADDR memaddr, unsigned char *myaddr, int len) ... Client: target_xfer_status remote_target::remote_read_bytes_1 (CORE_ADDR memaddr, gdb_byte *myaddr, ULONGEST len_units, int unit_size, ULONGEST *xfered_len_units) { ... decoded_bytes = hex2bin (p, myaddr, todo_units * unit_size); /* Return what we have. Let higher layers handle partial reads. */ *xfered_len_units = (ULONGEST) (decoded_bytes / unit_size); return (*xfered_len_units != 0) ? TARGET_XFER_OK : TARGET_XFER_EOF; } Thomas