From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id YeAkA+rMl2diaRwAWB0awg (envelope-from ) for ; Mon, 27 Jan 2025 13:14:02 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=osandov-com.20230601.gappssmtp.com header.i=@osandov-com.20230601.gappssmtp.com header.a=rsa-sha256 header.s=20230601 header.b=VKrQWdKc; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id EAE7B1E105; Mon, 27 Jan 2025 13:14:01 -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.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,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 987BE1E08E for ; Mon, 27 Jan 2025 13:14:00 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 218C0385843F for ; Mon, 27 Jan 2025 18:14:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 218C0385843F Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=osandov-com.20230601.gappssmtp.com header.i=@osandov-com.20230601.gappssmtp.com header.a=rsa-sha256 header.s=20230601 header.b=VKrQWdKc Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id F32513858027 for ; Mon, 27 Jan 2025 18:13:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F32513858027 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=osandov.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=osandov.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org F32513858027 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::629 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1738001593; cv=none; b=sN2M4xAGUpqJ2VnLI2o4MkyxNVL87eokWbJe1BH/dnPC4EJ3UbLtPp9jofY2UYobdVRmKwZrCiahukuif3wdrBbEUjZVCo+3V9k5GF9o7t2HLP9xoMfTrg68tdjlxI93yLO8Jc8x8zZo3mbf3cnBzvhhZgXLUFLAtevu1AUiOiY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1738001593; c=relaxed/simple; bh=l1eACB6VOP/K5eHnZbXpEqIFYHkMBahEyK2W7oIxoQA=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=tBIoszggtfyOBM68qKuyLDsLyxtRf1XdC4f/KUTbeEdTb7I0nRHZ8QPlRpebbuzWNwfJ8LN9l2qiTqL78EAOZfvgUd3k8XF5fzTPa7gfKVfWMnV/MnSTYMEz/e/M3J6oOwQZocWhHnwYncfpOAWMIEZ+oH1sjkUlwBD3abnlwGE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F32513858027 Received: by mail-pl1-x629.google.com with SMTP id d9443c01a7336-2166db59927so8612655ad.0 for ; Mon, 27 Jan 2025 10:13:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osandov-com.20230601.gappssmtp.com; s=20230601; t=1738001592; x=1738606392; darn=sourceware.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=fnLx9RRbje92P4z872lWJ7+dC+DyQSwf7FphHZKrZFY=; b=VKrQWdKcVdMRqaBeze9W48o6PEWhcuZKpZG01hKqu8mukz2urrDT/qz4Xd39enjW0f PiRHJTqy6kndNEyxU0pJRMJwGDw9irNj7xzbsVAmZl/lxZjUFtXYX4twPXBydvvvNc1V HsPs0Z4Dwa6gpBM4OkY6zkSTju3OFnTs1nrUC/5pE6u+D6OjaqG2Ld9n1BZoNQL/gf2v bCO6WdBR55BFQvch5DEeFSlRr+SDGu5B0490t2w1dvNnrz5yUz8hY1jxikHoAwOCy08H cokj6aPi6qSEoyFXKL1M0meeRRLVlnFdcbmYqoEfJ28QjFz+I5nnYXL2JlSjtDkge8r4 M2yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738001592; x=1738606392; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fnLx9RRbje92P4z872lWJ7+dC+DyQSwf7FphHZKrZFY=; b=hmdsp78kL4qu2n2x8I/WVUa0bROm+Gv3ATQsIKUJQQU4vu53Bfxvj4vc/CbuoY9gxm A+rrBxafV1/pWeF5du0yyYS9EIUWVQSK33DveufzMB7Utg0OgkYepumaFft4HSa0wHI9 cj17xiAJ8531jbaJwwAcx+rBaFD2sBSzsdz88cg10kz+Pe6iuDW5fL5aNR7D7t1yG7QL GpZzTm0ZJyJg6MxXYzstKTxJQrXK5mFwEyWwExY3jAJgdGoFITMb6BSF5eHYztbR2pUN ZWVXd7xpdo2laH4iSkig4taYEz84DaTCdRW5asa+xkkyy5WZKzJnvrfGInxL4lx4Ds3l aGJA== X-Forwarded-Encrypted: i=1; AJvYcCWKwmSytirOsn9QW+59riu9dow8jx9LMOM4656ucxn0DaembwyZlEeknfVwBg8miljb/10=@sourceware.org X-Gm-Message-State: AOJu0YzHmcQx3XaZIsqTmZTTwC0KptSD0ZLOi6cnhEux1UCFcTglUg9p 4s6zl0hc6bALk4umDauonafyl2X+itZVQ4HCcXJ8cbKc9RXhIRE4HDa9cDqXP50= X-Gm-Gg: ASbGncsifdK7HLZBYLX6xtBVQ0KIzlbiOeXpw4Mxruv0lYzKhw5Aqe25wt+9jPyd9HF N//9i06LyCPZr1b91AY8yrkkCaIzX44JiHYs0T7wqKyrexyMWDiF4MnYVG2efQFg1TvN/hLDIYy 0nuGMlfVjA9y/GXsTsdgEN/yCzuXKh2ec9Qm5Zha0gl+klOAXNEjXAd3mKOIJ74n3nOjMp6OKjx pr/xnxeWUcx+Zn5F/lZPKfssTdPj/FSgc67S3sHcPQ0Leqlu0d/N+U9qrjg/hA= X-Google-Smtp-Source: AGHT+IFWsQ1hlX3mWS9JaFfWM8KKgebPj+qlMBX9Cq6URG6Ti6gAM9WwWG9ffAHaihBdDY1n1E4/og== X-Received: by 2002:a17:903:2449:b0:215:a3fd:61f8 with SMTP id d9443c01a7336-21c3563f1b5mr248314405ad.10.1738001591852; Mon, 27 Jan 2025 10:13:11 -0800 (PST) Received: from telecaster ([2620:10d:c090:500::6:926]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-21da414151fsm66588995ad.121.2025.01.27.10.13.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Jan 2025 10:13:11 -0800 (PST) Date: Mon, 27 Jan 2025 10:13:09 -0800 From: Omar Sandoval To: Thomas =?iso-8859-1?Q?Wei=DFschuh?= Cc: Stephen Brennan , gdb@sourceware.org, linux-debuggers@vger.kernel.org, Amal Raj T Subject: Re: GDB Remote Protocol Extension - Linux VMCOREINFO - Request for Feedback Message-ID: References: <8734hmtfbr.fsf@oracle.com> <766010fa-49a5-4e86-a730-bf79bb73e928@t-8ch.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <766010fa-49a5-4e86-a730-bf79bb73e928@t-8ch.de> 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: , Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" On Sun, Jan 26, 2025 at 07:07:47PM +0100, Thomas Weißschuh wrote: > Hi Stephen, > > On 2025-01-13 16:22:00-0800, Stephen Brennan wrote: > > I contribute to the drgn debugger [1], and work on debugging the Linux > > kernel a fair bit. Drgn is particularly well-suited to the Linux kernel > > and contains a lot of support for it. It currently supports attaching to > > live targets via Linux's /proc/kcore, and core dumps. We are looking > > into supporting remote targets via GDB's remote protocol. > > > > One piece of information that is very useful when debugging the Linux > > kernel is the VMCOREINFO note[2]. This is a free-form piece of text > > data, typically around 3k bytes, which contains information that > > debuggers would find useful in interpreting a Linux kernel memory image. > > In particular, it contains the KASLR offset, the build ID of the kernel, > > and the OS release. With this information, a debugger could attach to > > a live GDB stub (e.g. kgdb, or QEMU) without needing to specify > > debuginfo file names or memory KASLR memory offsets. > > > > To that end, we hope to extend the GDB remote protocol with a facility > > that would allow the debugger to request this information. We've written > > up an idea for this proposal at [3]. The summary is: > > > > 'q linux.vmcoreinfo' > > Retrieves the Linux vmcoreinfo data. > > Reply: > > 'Q [DATA]' data is encoded as described in the Binary Data doc [4] > > 'E.' with an informative message if the data is not available > > > > However, with the candidate kgdb implementation taking shape [5], we're > > becoming concerned regarding this design. It seems that there is an > > implicit maximum packet size which is not described in the protocol > > documentation. Many stubs have small(ish) shared output buffers. It > > seems to me that data which would be 3k bytes before escaping is too > > large. We've noticed that there is a 'qXfer' query packet which allows > > specifying an offset and a number of bytes. Maybe it would be better for > > us to add a new 'special data area' for the 'qXfer' message, and reuse > > that command? > > 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. 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?