DavidSpickett added a comment.
> Given how often the '0x' prefix on base16 numbers is dropped in the remote
> serial protocol
Now you mention it, I thought I knew how strtoull worked but I don't. (I
assumed it was some best effort that would roll back if somehow the digits
didn't fit the assumed base)
This is what a gdb pread looks like:
getpkt ("vFile:pread:6,3fff,9ab473c8"); [no ack sent]
So in fact it is doing exactly what you said and not including the `0x`.
> What do you think?
Yes I think sending hex with the `0x` is the clearest indicator for
implementers of their own lldb-servers. However gdb-server doesn't expect the
leading `0x` (I don't see the spec mandating it either way) so it doesn't solve
that side, if that is a goal.
So would it make more sense to change lldb to send unprefixed hex like gdb does
but update lldb-server to accept either? (by trying base 10 then base 16).
Especially if implementers are going to prefer the packet specification over
reading packet logs from lldb.
That's not perfect either, an older lldb-server with a new lldb client could
happen to parse the number as base 10 but you'll get a unexpected result. (at
least adding `0x` would give you a hard error there) Do we commit to that kind
of compatibility?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D89227/new/
https://reviews.llvm.org/D89227
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
