Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Pavel Labath via Gdb <gdb@sourceware.org>
To: Andrew Burgess <aburgess@redhat.com>,
	Luis Machado <luis.machado@arm.com>,
	"Aktemur, Tankut Baris" <tankut.baris.aktemur@intel.com>,
	"robert@ocallahan.org" <robert@ocallahan.org>,
	"gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: Incompatible implementat ion of 'x' packet in GDB vs LLDB
Date: Tue, 28 Jan 2025 09:26:02 +0100	[thread overview]
Message-ID: <174eaf99-737b-4b2a-a2a0-49282748cb62@labath.sk> (raw)
In-Reply-To: <874j1pmib7.fsf@redhat.com>

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

  reply	other threads:[~2025-01-28  8:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-22 19:57 Robert O'Callahan
2025-01-23  7:12 ` Robert O'Callahan
2025-01-23  8:13   ` Aktemur, Tankut Baris via Gdb
2025-01-23 11:23     ` Robert O'Callahan
2025-01-23 11:39       ` Luis Machado via Gdb
2025-01-23 16:14     ` Andrew Burgess via Gdb
2025-01-23 16:33       ` Luis Machado via Gdb
2025-01-23 17:28         ` Andrew Burgess via Gdb
2025-01-23 19:38           ` Andrew Burgess via Gdb
2025-01-28  8:26             ` Pavel Labath via Gdb [this message]
2025-01-28  9:25               ` Pavel Labath via Gdb
2025-01-28 10:15                 ` Luis Machado via Gdb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=174eaf99-737b-4b2a-a2a0-49282748cb62@labath.sk \
    --to=gdb@sourceware.org \
    --cc=aburgess@redhat.com \
    --cc=luis.machado@arm.com \
    --cc=pavel@labath.sk \
    --cc=robert@ocallahan.org \
    --cc=tankut.baris.aktemur@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox