From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 0HWkBMuUmGf9+hwAWB0awg (envelope-from ) for ; Tue, 28 Jan 2025 03:26:51 -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=SRHt5kgF; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 085641E105; Tue, 28 Jan 2025 03:26:51 -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 76A261E05C for ; Tue, 28 Jan 2025 03:26:50 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id EC353385801B for ; Tue, 28 Jan 2025 08:26:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EC353385801B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1738052807; bh=LYq/58NRXv7jx8IL0LQtyh/pucRg58wLlRAawuC7Srg=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=SRHt5kgFgPVWu+Hb6EFAzhWjUZIL1bM1HU6PejXazkj5hOY8NPt6K8oOOHvM1w9Pv zJFJLm4kmjSPZfwgUZ0dqwfTdn2CYaaqgdkym9iXhpYigdubZNl4uz0XpIp9oGlo+x De9Jb3Hk4GmkSg01Acntk9c5ZLPCAcH7v4HDSr7k= Received: from holomatrix.labath.sk (holomatrix.labath.sk [92.48.105.150]) by sourceware.org (Postfix) with ESMTPS id 779AC3858D1E for ; Tue, 28 Jan 2025 08:26:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 779AC3858D1E ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 779AC3858D1E ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1738052765; cv=none; b=ZMKNhWts9wjcv/WljMb2nWPxAdHaaH1WzgpRTOLdakXZ5/eoN7X79dOJ7rmQdp0t40IZZ9Unu5vMWloTJZBoO9QQkLogjf9FseFqOU23xWAfN11lyAyxWFNsDG6W9taXCnxFMf51F6hmdKe6N1bznTolhBT6XEE+M3EjEgACky0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1738052765; c=relaxed/simple; bh=/tBFjGFX/mSZLHohaa3/Fu3BOCUNgCHtNjWmDyG1t3g=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=Ms/n57vTRPeFVay4sEUyHsiuDm3nDgW4Q5REHb7Xou7L/GkIOKTqNBae1j6jc9IwI2E3fcUo6RRoyfoWuc25brl1T8t1Hfd61v4ASJfTNDdRnFkrpdCIgTnBrW3iX7cUR+NtHOGsIV9j2AlT8YYuJ8pJ4ZqyeJ2oN8U8GxLfaf8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 779AC3858D1E Received: from [172.21.6.108] (nat-vidiek.mag-net.sk [195.168.209.2]) by holomatrix.labath.sk (Postfix) with ESMTPSA id 01ED74147C; Tue, 28 Jan 2025 09:26:02 +0100 (CET) Message-ID: <174eaf99-737b-4b2a-a2a0-49282748cb62@labath.sk> Date: Tue, 28 Jan 2025 09:26:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Incompatible implementat ion of 'x' packet in GDB vs LLDB To: Andrew Burgess , Luis Machado , "Aktemur, Tankut Baris" , "robert@ocallahan.org" , "gdb@sourceware.org" References: <87a5bhmrre.fsf@redhat.com> <877c6lmobo.fsf@redhat.com> <874j1pmib7.fsf@redhat.com> Content-Language: en-GB In-Reply-To: <874j1pmib7.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: Pavel Labath via Gdb Reply-To: Pavel Labath Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" Hello everyone, an lldb dev here :) I'm sorry for the trouble our implementation of 'x' has caused. I have to admit I was surprised to find that the packet was not in the gdb documentation already. It's been implemented in lldb for as long as I can remember (~10 years), and the new packets we're adding nowadays have much longer names, so I had assumed that it was always a part of the gdb spec. For what it's worth, I think your definition of the packet makes much more sense. LLDB's definition is indeed ambiguous (and I didn't realize how ambiguous until now) -- it cannot distinguish between a (truncated?) memory read and an error. This behavior is not completely easy to trigger because lldb will by default round the memory reads to 512-byte boundaries (so truncation is unlikely), but with the right commands, I was able to get it to treat valid memory as an error. For this reason, I am going to propose to migrate lldb to the gdb ("official") definition of the packet. Since we have users which need (fairly long) windows of compatibility with old server, this is going to require method to detect the implementation in use, so I'd like to reuse the same mechanism that's going to be used in gdb (both the zero length probe and the qSupported method seem fine to me). regards, Pavel