From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id O3+FMaThiGf49BAAWB0awg (envelope-from ) for ; Thu, 16 Jan 2025 05:38:28 -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=Elr2ZyAS; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id BC0781E100; Thu, 16 Jan 2025 05:38:28 -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 1AFFC1E08E for ; Thu, 16 Jan 2025 05:38:28 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A73423850851 for ; Thu, 16 Jan 2025 10:38:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A73423850851 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1737023907; bh=afz+4OE353qB0XJ9A5iXAn0NbAmdnjPqioq2MmMR2Zk=; 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=Elr2ZyASetlasJvR7rxPPNC4aFOh4U7mqlIjPo/W4IyU/uIwBAsoIB/gTUTSGLMoD HRI2pqhFxuxRn52YNm29kfdNDxc/4yQrWl9mbpLENHyWbbyr839ZQOEpxTaggZT3wm XdpDc8UcgW640qTksChBEp0lPgMKyVxuFxxyR+sI= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id AE1FD3850872 for ; Thu, 16 Jan 2025 10:37:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AE1FD3850872 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org AE1FD3850872 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1737023849; cv=none; b=UNUbrAst/VKF7gMl+f1sg1aydW1dWwsfH6wC96hWgcwX8EqKyQgYoJGyLfEF5KRlzBuu+bqpvuX+VBae7pLn53HLoLskzLd1ugFA7Oo45VN1vLxr8EdxvXbDbPC06i7OPjz8zTFwV60J7o1CRBE6PL/bbXpW25OqZweAHX5OmGI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1737023849; c=relaxed/simple; bh=qK8XQfN1Gk5nwFHGzeJNW/hu7t6k2hFTZHLZPJUrwUE=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=l2MYB8Bu2YRpKG/o8whBzDAlgBM/UTAZPlX79gZARrucRUkhV0hZY5CbcETME1zRSv0Sz5HNcsjN/+YrVSBKEyFquNHQFYfo0XqkLiC2pAr240kGwiLuOnQsZZCLDrHUr1Rqtd3bO/6lNOXBS5Imm5Rtky76IiNgvl1nVeGEwqM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AE1FD3850872 Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-510-iXbDlLswM2SFxOmPZ9Z6Tw-1; Thu, 16 Jan 2025 05:37:28 -0500 X-MC-Unique: iXbDlLswM2SFxOmPZ9Z6Tw-1 X-Mimecast-MFC-AGG-ID: iXbDlLswM2SFxOmPZ9Z6Tw Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-4361efc9d1fso5064935e9.2 for ; Thu, 16 Jan 2025 02:37:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737023847; x=1737628647; 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=afz+4OE353qB0XJ9A5iXAn0NbAmdnjPqioq2MmMR2Zk=; b=Fej2UHjFMhQsrm1h6ROel1O/A28htPBBjBG0nO4wsxbM+qVMY9LbQ50tqA47pDutXL cyfUc2cYEPgbDuSifuXgoKi3cmMc339nK6S8fTVwNJmL2t/5cvxeuRhr17uST0FsSai7 e74CFKCbv2qRafm/sSf1roI4TgWTovaQmUmaI6/7Y2f5Tf322jFojLcrJcXDNCXcQGFz m2Sb1FbuTPzDP8/pPXTeStJqaFAmUJiHw4Rdpi+bXfF9Kq+ady4pmd08VQXfGkycKh75 fmKoTCfSsqgqnVPv26W3miHjeher+SiOLBiABkZLeH4BUdKIcrEGxC7n236MOxfVjY/r 3zkQ== X-Forwarded-Encrypted: i=1; AJvYcCUho6Kst6ulsGxhx2yiY8aV0uS+aYOTwu2Gxxcoen3OsvER1sTmXyy8u9Kphs9b4i0IZWI=@sourceware.org X-Gm-Message-State: AOJu0Yx7EHqxy2MRS3cuh/O49cDsiwmHorwYYhoXa2+Kjcpo1OcJt6tj 9EqqGOCCL2Fb95b9YxdUzjKRgcbzGqRAMfk0d5iH1q304hLTLiS3AAhwLB/mpD3Jt4SmTUYscMl wPH2eCQXb5QAJgtSZ3mUayZU5pyGY2OF/o0cDBkG/QeLXVa5k X-Gm-Gg: ASbGncskkrT9xu5ngLU6Q3qJN0BywxYtjoHMkEg3TR2RGojps4ZDElJphSoNdhm9Epc FUS/u2p4CiSClnQaqLrMJH2buW4f9yyrmFKQhvaSjmAOxw0kTuw0Asyl+zq4KRSZxnjdL79HYNL inpGOi+rIZCfrlv8ycgtD14i3aexSNWsuq0BEHTOOyxn1x7ayCY98OyTEsjXZxc/4VVoOU+V2kW GpnKAZ4FyatG/og+gcjLmA+A7eFkKkzuuEz58cqF6z1Usvcm69s5nFFDqTg/VVd6vYlEBUIslLr +KXWAg== X-Received: by 2002:a7b:c315:0:b0:434:ffb2:f9df with SMTP id 5b1f17b1804b1-436e26adf94mr318507855e9.17.1737023846891; Thu, 16 Jan 2025 02:37:26 -0800 (PST) X-Google-Smtp-Source: AGHT+IEBidBGhIPwJqxDq13P32Iam9aSzh2FtZ725kNmxULef90vbPBbLPIKwp3AeJW+9asUJ+lSnQ== X-Received: by 2002:a7b:c315:0:b0:434:ffb2:f9df with SMTP id 5b1f17b1804b1-436e26adf94mr318507565e9.17.1737023846514; Thu, 16 Jan 2025 02:37:26 -0800 (PST) Received: from localhost (44.226.159.143.dyn.plus.net. [143.159.226.44]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-437c74c475csm55593135e9.20.2025.01.16.02.37.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jan 2025 02:37:26 -0800 (PST) To: Stephen Brennan , Tom Tromey , Luis Machado via Gdb Cc: Luis Machado , linux-debuggers@vger.kernel.org, Omar Sandoval , Amal Raj T Subject: Re: GDB Remote Protocol Extension - Linux VMCOREINFO - Request for Feedback In-Reply-To: <87y0zds39y.fsf@oracle.com> References: <8734hmtfbr.fsf@oracle.com> <5e1c692b-b103-4c47-8cc3-d8ce487d98e1@arm.com> <87plkpqpuj.fsf@tromey.com> <87y0zds39y.fsf@oracle.com> Date: Thu, 16 Jan 2025 10:37:25 +0000 Message-ID: <87cygnoxi2.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: qnBUC6DktHab8vP-LakqhvgqNH7CGpOLVanvyObu9sc_1737023847 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" 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. The benefits of using a Python API are that you can ship the extension with the kernel, so if/when the vmcoreinfo changes you can easily update the extension. At the very least, it allows you to prototype your commands before having to submit patches to GDB core. I have included below a very simple example that implements 'info stuff' which just displays the 'threads' information from a remote target. Place the code into 'cmd.py', then from GDB 'source cmd.py', after which you can 'info stuff' and 'help info stuff'. If this is an approach that might be of interest then I'm happy to help in any way I can, just drop questions on the mailing list. Thanks, Andrew [1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Connections-In-Python.html [2] https://sourceware.org/gdb/current/onlinedocs/gdb.html/CLI-Commands-In-Python.html [3] https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/testsuite/gdb.python/py-send-packet.py;hb=HEAD#l100 -- def bytes_to_string(byte_array): res = "" for b in byte_array: b = int(b) if (b >= 32 and b <= 126) or (b == 10) : res = res + ("%c" % b) else: res = res + ("\\x%02x" % b) return res def get_stuff(conn, obj): assert isinstance(conn, gdb.RemoteTargetConnection) start_pos = 0 len = 10 output = "" while True: str = conn.send_packet("qXfer:%s:read::%d,%d" % (obj, start_pos, len)) str = bytes_to_string(str) start_pos += len c = str[0] str = str[1:] output += str if c == "l": break return output class InfoStuffCommand (gdb.Command): """ Usage: info stuff Shows the remote targets thread information. """ def __init__ (self): gdb.Command.__init__ (self, "info stuff", gdb.COMMAND_DATA) def invoke(self, args, from_tty): inf = gdb.selected_inferior() conn = inf.connection if not isinstance(conn, gdb.RemoteTargetConnection): raise gdb.GdbError("not on a remote connection") string = get_stuff(conn, "threads") print("Target thread information:") for line in string.splitlines(): print(" %s" % line) InfoStuffCommand ()