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
next prev parent 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