From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id bcmeD5d8kmcorhgAWB0awg (envelope-from ) for ; Thu, 23 Jan 2025 12:29:59 -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=curAk8T/; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 32DF01E100; Thu, 23 Jan 2025 12:29:59 -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 8EEE31E08E for ; Thu, 23 Jan 2025 12:29:58 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1FE523858423 for ; Thu, 23 Jan 2025 17:29:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1FE523858423 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1737653398; bh=FJrBG6xQH6x1Pz7IWmXxt4uEptE0QzuYhubX2UTUeGo=; 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=curAk8T/Y7jzcp+LKwkgP+a/uaGyq9t2qLqj3AVNHctIuKTnviEzBkP7ZuzwdhtdB WWUgNQatf1z8sPtQ6f1DHs7NVVcLZ5ZJn2uW1JskPzfOOhnh2Eevvti7IMAIsFn9RO EGx8gDgAvZJeFPR+HAPjl2QBKrBlAWb+RRjiZOXs= 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 1F4493858D3C for ; Thu, 23 Jan 2025 17:29:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1F4493858D3C ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1F4493858D3C ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1737653344; cv=none; b=foWHYvpJ7VFm12yEnvBA+77qDTCYxGud0gHHDGiXTqW9kUNpPgoJsSsLIAh7THLO8ggpLOuND2xIzb7XGqNYfSypBagvy603y/jfNdDCciRzyAFFfQg78spvY2Bw5pxML9brdVkGauHy0k2I0mC59WykIfZucWz5F5QSMpG/iJw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1737653344; c=relaxed/simple; bh=FzWgP6Nv6Dofk6GxiiNfWQX2XLkTngTYJ3DRaIHTSxc=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=Fuj/exev8r1DgrZPZa+Z8b4Nt4fUWlKQw6B5lgUtZCzMYsIs1NLscmlcPKpAqncJ8ATPwAa9x7knwkNKvw/1mTf/pmAdBLVn07wKaKn8h9EuFxdfy7IqDxpYNLBCQ8u7qDF3Y7p+MxgFf+csG/Sbk5LijGzBbckD+BEoTFjSnQQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1F4493858D3C Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-134-2lYC5q2-MI-GvS_vUrv5xQ-1; Thu, 23 Jan 2025 12:29:02 -0500 X-MC-Unique: 2lYC5q2-MI-GvS_vUrv5xQ-1 X-Mimecast-MFC-AGG-ID: 2lYC5q2-MI-GvS_vUrv5xQ Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-43582d49dacso8337025e9.2 for ; Thu, 23 Jan 2025 09:29:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737653341; x=1738258141; 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=FJrBG6xQH6x1Pz7IWmXxt4uEptE0QzuYhubX2UTUeGo=; b=b3k2agkuocVQz+mWFybCKCjIwaoxb1kW8T0h08ptODxP+yspsYwkhSZgu73Qw7kQ2l AWGgeik3p2inc6HFUYcRWSk0Fp/awbqUvXa68rvNKyrbQ/bidV39RZkl+mGFSN4HwLAm 4R81qWIld0VK2pSJos7Vruj4/pAE+K79qJuHaucxmPZNNWmYXB1Eqw8PyRBpJAtG4j6r jKrbGFrH06Cr3vQ1gWwdIuRGqO2PLL0b47OkG/POiMbQWOQHuqSTmGS/jWc/YSQ7cujm 06LoLbeHmYFcEVqKMN8pZFdfeIyv5zpN2eB8LjjjjIhVoCCmDRIfmoFc6VS5Z0JHK6ZE HdAg== X-Forwarded-Encrypted: i=1; AJvYcCVJ3JCU8vrPfq/2KEc3agAnSdMdQZpmTUnXbGLcwYLPMbTrqvZkTyE4CjJbcX+ZmfVwr1A=@sourceware.org X-Gm-Message-State: AOJu0Ywgrf1w9uVeN1sdC31ot400qsGPZZGE30vdpSFBHkd1iYZU1A2o gBQ+TGMjVrv8z/m/z7gaJ0svEa0cIV2Vo2BkujP/CAOwc4TV9JBL1P3AnRvRsbao3ONUPal46bV th2MLxHWAKLQXgSNfaT/btiEw/w93E9zhzs814HQSLmsJffNi X-Gm-Gg: ASbGncuIPCes9z4ty1vIRflpgEX9nl/3758nQUS9pUmi0QSqy3qUlBgTYN/V5NYi26t XbtX37ixlN17QHY7VQq5GffpeN23rjHE/2VyFI5OmyTAX8iQK3YUaoD6A8/ZD9OqTww7thyol5/ pYK/ePf2n1qcYfZP189JgQUWjYPd4Q/2WO6ke373oI5z2xf2RuV1EFcAK0yZ5fQ2jYmC5IzGWuj JTRMPazWhe1hDFGxp0jocPRYNZRvGM4DOd9Dzr5xiji0VRCxT/sAeWF9NK5z/4iJxJp3qtYQJyS e7pqwriwYeKEQqhi13Q= X-Received: by 2002:a05:600c:4fc1:b0:434:f218:e1a8 with SMTP id 5b1f17b1804b1-4389141c21cmr212901525e9.19.1737653341166; Thu, 23 Jan 2025 09:29:01 -0800 (PST) X-Google-Smtp-Source: AGHT+IGe+cQtWw1xaGbI35dc60XYKj8o8JPqZF2f7Om8aMmE8r09Rf3r9GpR0A4LvIFLMEqjF9lfUg== X-Received: by 2002:a05:600c:4fc1:b0:434:f218:e1a8 with SMTP id 5b1f17b1804b1-4389141c21cmr212901275e9.19.1737653340773; Thu, 23 Jan 2025 09:29:00 -0800 (PST) Received: from localhost (44.226.159.143.dyn.plus.net. [143.159.226.44]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-438b31d9a51sm68620435e9.28.2025.01.23.09.29.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jan 2025 09:29:00 -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: References: <87a5bhmrre.fsf@redhat.com> Date: Thu, 23 Jan 2025 17:28:59 +0000 Message-ID: <877c6lmobo.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: AxW0mf_z6tC1pxzdaCqXCsyiVi0gojYAEo78L2IOlCM_1737653341 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/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. Thanks, Andrew