From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id hSfuKgCbkmdNyBgAWB0awg (envelope-from ) for ; Thu, 23 Jan 2025 14:39:44 -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=JHyN+MLG; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id A154C1E100; Thu, 23 Jan 2025 14:39:44 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.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,RCVD_IN_MSPIKE_H2 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 BDA211E05C for ; Thu, 23 Jan 2025 14:39:43 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5F10A3858C52 for ; Thu, 23 Jan 2025 19:39:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5F10A3858C52 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1737661183; bh=8CGEqOTPMqUrCW2ITHe89ysNUi21/sqn1e0U/JO2AaI=; h=To:Subject:In-Reply-To:References:Date:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=JHyN+MLGJT1RMIcd8ijzoj0+Dh+nyiexLXQ7PxId0BUGRbX5tXHTgg3ZxXaglkchC wpLhYHaRHDoJoPzyqdUoXjpObVj5kaU4bXTe1BfhqwNpzJhrfYczQytDv8GL+bCQQ+ gUdz/GvUtYxywlPazZKSS7lJApsen4FSiQi9r4Rs= 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 5D6C83858D26 for ; Thu, 23 Jan 2025 19:38:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5D6C83858D26 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5D6C83858D26 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1737661137; cv=none; b=AB1NhbrYRQn60U0m4h168VjjgLjHAbBJRqo7adx2cIk34S6NADrcxcQdfZf4PWRxw0I1g4f7tajTqScfC78YrUTaiy3S4/ExUxpxO48M+ujOvijLxbG4dRCZldrA+5sJ0IgHzXNlK74vcovSvqjOwZugG8MlTsmwux4Sq5ENUxI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1737661137; c=relaxed/simple; bh=RAqm/703owP1ChEUvAkaY0Jw8sFWA8KpBqmvMSphCBA=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=aK/q+UByLt9O2IwRP3GmduUsxZhRAXnc/7P/8Xnx5mCb01iWx68r/z26USAMWt30M4GPR14oQ//vWR0Z1UEyy0rW0y92r5ESiTgdiMqzaSroB/HLWmeKql0dzB3cBhvq3x+sS9K8zCxASO73Ivcdoy6SxgVLef5cQ4f0mCFqXLg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5D6C83858D26 Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-407-wTRVL0HjOb2sJrjRifGHwg-1; Thu, 23 Jan 2025 14:38:55 -0500 X-MC-Unique: wTRVL0HjOb2sJrjRifGHwg-1 X-Mimecast-MFC-AGG-ID: wTRVL0HjOb2sJrjRifGHwg Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-38bf4913659so1036631f8f.1 for ; Thu, 23 Jan 2025 11:38:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737661134; x=1738265934; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8CGEqOTPMqUrCW2ITHe89ysNUi21/sqn1e0U/JO2AaI=; b=wb0uz71ZL5jlZawcA7HhCt+9UpJgEk3emYr6JLJVcvWWAR34DFl1mrqt3XDqdSKke/ v3oxnU1j+SYGLcgAbaD0D0qLIyL33oaU81jm0yTNfQQg2jwI4lEhe4p5/TJgqS4QP9DJ doJNoN/627tisgHMV2YZzABjbQLcjPGVkCWyWmHoI6UGu6F4XZwe1/XhfVnJzahAo+IK 3hd2rXohb83VPTqyquGTQFrvPO0CrhAF+rZzJZxSsKlfvtstLd5UHZGV3pztGQn4Jkdr OaJzJcoZLK77m/1CJW+zOzzZOECp2g5sM7zeQcKPx0Z3pMczbu2z7KOjK+g6KOPIpcaU dc6Q== X-Forwarded-Encrypted: i=1; AJvYcCXdABUj4F5/MtVdYah64tr6wAZjbxUkXfBWzstJavcjpOsE+dMbEOy2dE7dUtKEu95Jol8=@sourceware.org X-Gm-Message-State: AOJu0Yxz6Qc4hvvaEPpe2OUgBabn8AT58KFDi6jh2mI+IBpvWAEU6Kn4 DO550G78/TvR44NTgUfEgMqoItFjaC+NnOrNK0+7kIJWJIftfH1DUYqO2a8MFd11sEwIK3aTU1V Ohoc/l45kN7ZphdSjIlza340x6TeBCnOc5N2ROKcrPUFFGxm4z1JXFxco X-Gm-Gg: ASbGncu44qHzgucb32K7DRuoV7zmHpmvZ+eBz+qviB0MsOJS9Zl/ZuI+FejpFtzQ5hY o8JVbLaZdDtwGC5TLLYL0Bze8fa0lEZtwFde12oGI2Id1/XXD92jhciNN3SOdfpzf0zZu3P0lvX 5S32Xd4jupWW/O3rmFoE1wSHqsF79Nz1Jl1vMubUfvYJZVngZBJQqoom5ZxZYKGotd4fFAL6ltw sW2j83Mq8x/kvWLFDx3D/eAQwBxa7eqnFZXr9zUGMyO8p1f+FXgNda+/tVpNvIUZnKOXnz5gLt8 QW3jXWz8gVyfZt06vjQ= X-Received: by 2002:a05:6000:2a7:b0:38a:615c:8225 with SMTP id ffacd0b85a97d-38bf577ff42mr27868293f8f.15.1737661133888; Thu, 23 Jan 2025 11:38:53 -0800 (PST) X-Google-Smtp-Source: AGHT+IHYfgbgRWpjgFoR1G5fQmNnlCnkSlNJLIc08K90KgKPqRqE8YLKw7Ew2wKi2QBmWG/BkqX9rg== X-Received: by 2002:a05:6000:2a7:b0:38a:615c:8225 with SMTP id ffacd0b85a97d-38bf577ff42mr27868273f8f.15.1737661133492; Thu, 23 Jan 2025 11:38:53 -0800 (PST) Received: from localhost (44.226.159.143.dyn.plus.net. [143.159.226.44]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38c2a1c3558sm514545f8f.84.2025.01.23.11.38.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jan 2025 11:38:53 -0800 (PST) To: Luis Machado , "Aktemur, Tankut Baris" , "robert@ocallahan.org" , "gdb@sourceware.org" Subject: Re: Incompatible implementat ion of 'x' packet in GDB vs LLDB In-Reply-To: <877c6lmobo.fsf@redhat.com> References: <87a5bhmrre.fsf@redhat.com> <877c6lmobo.fsf@redhat.com> Date: Thu, 23 Jan 2025 19:38:52 +0000 Message-ID: <874j1pmib7.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 8ndv_88Rym4uxjDGP8j5nGdkbXUXwRdLk9Ze9_62Hr0_1737661134 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" Andrew Burgess writes: > Luis Machado writes: > >> On 1/23/25 16:14, Andrew Burgess via Gdb wrote: >>> "Aktemur, Tankut Baris via Gdb" writes: >>> >>>> On Thursday, January 23, 2025 8:13 AM, Robert O'Callahan wrote: >>>>> On Thu, 23 Jan 2025 at 08:57, Robert O'Callahan >>>>> wrote: >>>>> >>>>>> GDB (client) 16.1 started sending the gdbserver 'x' packet. It follows the >>>>>> documentation [1] and expects a leading 'b' in the response [2]. >>>>>> Unfortunately LLDB has supported this packet for quite a long time [3] and >>>>>> does not expect a leading 'b' in the response. We added support for this >>>>>> packet to rr last year and followed LLDB's format because it was the only >>>>>> user of the packet at that time. So GDB 16.1 doesn't work with rr. [4] >>>>>> >>>>>> I realize that compatibility between GDB and LLDB flavoured gdbserver >>>>>> protocols is not a priority for either team, but until now it has actually >>>>>> worked in practice --- rr hasn't needed a client mode switch. We can add >>>>>> one, but it will be unfortunate if GDB 16.1 and later is incompatible for >>>>>> anyone who's installed the latest rr since May 2024. >>>>>> >>>>>> Could you make a GDB 16.1 point release that removes the 'b'? AFAIK it >>>>>> serves no purpose. >>>>>> >>>>> >>>>> It has been pointed out that if you want to return different error codes >>>>> then you need the 'b'. Is that the rationale? >>>> >>>> Hello Rob, >>>> >>>> Essentially, yes. In case of an error, the server responds with an 'E' packet. >>>> To be able to distinguish an error packet from binary data, 'E' would have to be >>>> added to the list of escaped characters. Having the 'b' marker avoids that. >>>> >>>> Additionally, when the response is empty, per RSP, it means the packet is unsupported. >>>> So, in case of a zero-length request, the 'b' marker could help us distinguish the >>>> unsupported case from an actual zero-response. >>>> LLDB doc says >>>> >>>> To test if this packet is available, send a addr/len of 0: >>>> >>>> x0,0 >>>> >>>> You will get an OK response if it is supported. >>>> The reply will be the data requested in 8-bit binary data format. >>>> >>>> How does LLDB distinguish an "OK" response, an empty binary data, an error, >>>> and an unsupported case? These were not clear to me from the docs. >>>> Is the x0,0 query special-cased? >>>> >>>> For the record, the 'x' packet series were discussed in >>>> >>>> https://inbox.sourceware.org/gdb-patches/cover.1710343840.git.tankut.baris.aktemur@intel.com/#r >>>> >>>> with the part specific to the 'b' marker in >>>> >>>> https://inbox.sourceware.org/gdb-patches/87msq82ced.fsf@redhat.com/ >>> >>> I also am not entirely sure how lldb's implementation can work in all >>> cases given their description. For now at least, I still think we made >>> the right choice with our implementation, though I guess if we'd known >>> we were diverging from llvm we might have picked a different letter for >>> packet in order to make it completely different. >>> >>> I have two thoughts for things we could do to possibly help with >>> compatibility here though: >>> >>> 1. Hide the 'x' packet behind a feature flag. So instead of using the >>> empty reply to indicate 'x' packet support, we ask remote targets to >>> send 'gdb-x+' in their qSupported reply. If a remote target sends >>> this to GDB then we will assume that they support GDB's style of 'x' >>> packet, and can make use of the packet. Otherwise, it's 'm' packets >>> all the way. >>> >>> >>> 2. The other option would be to probe for 'x' packet support as a >>> separate action. Right now probing is done the first time we send an >>> 'x' packet. The packet is sent, and if we get back the empty packet, >>> then we know 'x' packets are supported. >>> >>> But if instead, we sent a zero length read, then by GDB's rules we >>> should get back a lone 'b'. By lldb's rules we should get back >>> .... maybe "OK" ... or maybe the empty packet? It's not really >>> clear. But the important thing is that neither of those replies are >>> 'b'. >>> >>> So the first time we consider sending an 'x' packet, we send >>> 'xADDR,0', if we get back 'b', then we know that we have GDB style >>> support, otherwise, we disable the 'x' packet, and fall back to the >>> 'm' packet. >>> >>> Approach #1 is pretty straight forward, but I wanted to check what >>> approach #2 would look like, so I drafted the patch below. This patch >>> is pretty rough right now, but can easily be cleaned up. >>> >>> For testing this patch I hacked up gdbserver so it no longer added the >>> 'b' prefix, then I tried connecting with GDB. I see GDB send the zero >>> length probe, then switch back to 'm' packets. >> >> Thanks for the input. >> >>> >>> Questions: >>> >>> + Do people think we should change GDB to improve compatibility? My >>> thinking is yes, so long as the cost isn't too high. >> >> Sounds reasonable. I think we should too, as it seems to be good timing >> (just after the release of gdb 16) for us to try to improve this. >> >>> >>> + Do people prefer approach #1 or #2? I'm leaning slightly more to #2 >>> right now, but not massively so. If people prefer #1 I can write >>> the patch for that instead. >> >> Approach #2 seems to be a bit better from your description, as it checks >> things from gdb's side as opposed to chaging the server side. At least >> that's my personal take on it. >> > > I hadn't spotted it before, but we already have > remote_target::check_binary_download which checks the 'X' packet by > doing a zero length write. > > So I'm now even more convinced that #2 is the way to go. I'm reworking > my patch to add a remote_target::check_binary_upload for checking the > 'x' packet, and I hope to post it soon for consideration. I've posted my proposed fix for this issue here: https://inbox.sourceware.org/gdb-patches/3183bc4875167009274313529badbb1685042c76.1737660927.git.aburgess@redhat.com I started a new thread to increase the visibility. All feedback appreciated. Thanks, Andrew