From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id bMa1FQknkmfrYxgAWB0awg (envelope-from ) for ; Thu, 23 Jan 2025 06:24:57 -0500 Authentication-Results: simark.ca; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ocallahan-org.20230601.gappssmtp.com header.i=@ocallahan-org.20230601.gappssmtp.com header.a=rsa-sha256 header.s=20230601 header.b=AIgwoTmt; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 45B5F1E100; Thu, 23 Jan 2025 06:24:57 -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.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_INVALID,DKIM_SIGNED,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 D1F771E08E for ; Thu, 23 Jan 2025 06:24:55 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 50575385841E for ; Thu, 23 Jan 2025 11:24:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 50575385841E Authentication-Results: sourceware.org; dkim=fail reason="signature verification failed" (2048-bit key, unprotected) header.d=ocallahan-org.20230601.gappssmtp.com header.i=@ocallahan-org.20230601.gappssmtp.com header.a=rsa-sha256 header.s=20230601 header.b=AIgwoTmt Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) by sourceware.org (Postfix) with ESMTPS id EBA9E3858D3C for ; Thu, 23 Jan 2025 11:24:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EBA9E3858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ocallahan.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org EBA9E3858D3C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::830 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1737631448; cv=none; b=h/GRd+zWFT0LGTCzAleImBGI7SkJJjmztLMlLMAS3urSry1RdP5a28JBxB5QtWnxVyEz/OuRiSHKxi1ngleffqW2SI6k/zb7WEzxfPfw1rTOZWogg5Y/iKYB82h0005wEwcoEFwWaZnn6yleXBlFcErRuo6P5+bMGVKCb4SS6BQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1737631448; c=relaxed/simple; bh=CRQNH1ihJT1sn7mH8UPTboNyE00Rv+KonCSKDd9KnXo=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=NSBzBygY3dYUb+oF2/23kKbcVgq7YaDk5wvHz/mt+eJv3pAlVxJLAqxqe8USMnQguCnCvw0ep5A31YXhPnei7//XHx9NEzlOdmhJgmkb2mI0tnxkMG7Xd4/bz7Z38xHnISeDxfXsuxM854FLWs1+iGe7NmG8ibdIYdtFkMmMRWE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-qt1-x830.google.com with SMTP id d75a77b69052e-467a3f1e667so4713001cf.0 for ; Thu, 23 Jan 2025 03:24:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ocallahan-org.20230601.gappssmtp.com; s=20230601; t=1737631447; x=1738236247; darn=sourceware.org; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9wROsfZgaSi6K3NG90nGaGtiZSO9DfsFMuMU7SzejuY=; b=AIgwoTmtWa24yZRFHOWjd7HeIKm+UrzaoIDwm7FKMX6V1Mg1EV2ZXh/GJvnzfQaCKE +Gg5/iEF8lgnL3f8CVGVEGvjRBJdEUvNMsVlFxNvn/DTBtJdR1gygxefaQUwRwKNYnqL qjPKw353sjfXY9ObbnG8ApxeKF+B+Kb8JtPM+AcnIG5sMtJbQnTfaZRKhdYp+1o6f2lw 2CyByT/ZMLU3lkdAxKf1vc99AF9mx21zo6Nzu1LXBkRTHaXepzqwBZe+9TrmFW+vNdCK 8wjIUyT0C7lSpYDxSTl3LQOb98NBBuSuxFMZk/6Y69U6cgsnO/nC20Dbet5LM2kwfpiK 5++w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737631447; x=1738236247; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9wROsfZgaSi6K3NG90nGaGtiZSO9DfsFMuMU7SzejuY=; b=HGWYT+VItloVps3NNWC96COTRSdXbdVB1XFo08+EH9jpa6LNs0RJGReFlLup8M6ET0 e/Qm6oBLr1NABy+wZvyjJVmCtwhLbjcA8JuCT+mw87kNhazZ3eaviYt2+5Hgj4dgyk04 gBUUiTR1/i8rZHjaf1zPtLXgkGckkZGG5zVMhvO65q7Q+/6ZjoxWMbg+igvjpprL7avk SM/n9ptEDTD+DHxbPAkMoWa55CyMaJCBFjEZjHDqzA7+bbbqlG84G6bHBPWAJuQZT1jR e2h88JK9ZOtdvtHp+akd68Mxcfb+hqCGV76Ep/Yp2rmXHqLIhXG79BZ77WsS8xbmZ/Y/ 1DIA== X-Gm-Message-State: AOJu0YzIHxenJTnNYwoNIg25GPkT/3s1rymJKaqnOkHe8XspIXa1zb+A tgdm7BH3tpKDfmh13r1pMqeOyoiTqA940WR6HEaQt86W+SVtYtZVNOBhkmyX8tVs2CrGEUrr2Zw VMTVwzMtDlR69e+o1REOvUsXH5SyIO5hD X-Gm-Gg: ASbGnctrM9AyX7bhQ5gnnM75eBBBHLDRjL0tVFAwhybKVRdma8sfftpZuoX5yYvlWoT JF/YDnGRchDwPsyiFKRBHRkPTyMs7C44UxOHlHvcsKOwOjPG4GQdaRFToj1WtSX0= X-Google-Smtp-Source: AGHT+IEbB04sUJEsmnnVljwNzvGYyjTk+EfGNnZt4TaPhj7vgborBhPEbb1Th3qAlUrTeqIYDDdVdnAqA2GU+fDrn+M= X-Received: by 2002:a05:622a:1a1e:b0:458:5716:fbd8 with SMTP id d75a77b69052e-46e12b6874cmr374043841cf.32.1737631447057; Thu, 23 Jan 2025 03:24:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Robert O'Callahan" Date: Fri, 24 Jan 2025 00:23:55 +1300 X-Gm-Features: AbW1kvbvM78fvyIMPNKplSV9Z6XbSIp4DoLWmYtHML_lD988jtteERGnigVPAro Message-ID: Subject: Re: Incompatible implementat ion of 'x' packet in GDB vs LLDB To: "Aktemur, Tankut Baris" Cc: "gdb@sourceware.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.30 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: , Reply-To: robert@ocallahan.org Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" On Thu, 23 Jan 2025 at 21:13, Aktemur, Tankut Baris < tankut.baris.aktemur@intel.com> wrote: > 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? > Yes, both on the sending side and the receiving side: Send: https://github.com/llvm/llvm-project/blob/cb714e74cc0efd5bfdb3e5e80978239425bd83d4/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp#L723 Receive: https://github.com/llvm/llvm-project/blob/2e6cc79f816d942ab09d6a310cd925c1da148aa9/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp#L2517 Not ideal, although it gets the job done. 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/ Thanks. From the point of view of an implementer trying to serve both debuggers, it's unfortunate that no-one raised the question of what LLDB had done... maybe next time someone could skim the LLDB protocol doc (and vice versa on their side). The LLDB approach is a bit distasteful so I understand why you wouldn't want to follow it. But rr users who upgrade to gdb 16.1 before they update rr are going to have a bad time, especially because it manifests as rr+gdb just being mysteriously broken. GDB 16.1 was only just released and already three users have reported the bug to us [1]. The least hacky fix I can think of that you could do to help us would be to do the "x0,0" query thing to detect if the packet is supported and if so, whether it's LLDB or GDB flavour and use that. Whatever you do or don't do, for the future in rr I think we'll have to push "LLDB vs GDB mode" deeper into our protocol handling and make sure any new features are only enabled for the client that we have tested them with. It may be even more complicated than that because there are other clients like delve, although hopefully they can stick to e.g. the GDB mode. Rob [1] https://github.com/rr-debugger/rr/issues/3901 -- Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. Efil fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew hcihw, gninnigeb eht morf saw hcihw taht.