Fix lldb-server test suite for python3
authorPavel Labath <pavel@labath.sk>
Fri, 15 Feb 2019 07:47:06 +0000 (07:47 +0000)
committerPavel Labath <pavel@labath.sk>
Fri, 15 Feb 2019 07:47:06 +0000 (07:47 +0000)
commit0af864b4b2af54a9c238df793e50b2f81f956b78
tree0d9afe88d0682c5c31a726bb018756718c6dcf93
parentb302bd232407cb939b45b4aabb72d1ba24b37cb2
Fix lldb-server test suite for python3

Summary:
This patch finishes the python3-ification of the lldb-server test suite.
It reverts the partial attempt in r352709 to encode/decode the string
via utf8 before writing to the socket. This wasn't enough because the
gdb-remote protocol can sometimes (but not very often) carry binary
data, and the utf8 codec chokes on that. Instead I add utility functions
to the "seven" module for performing "identity" transformations on the
byte data. This basically drills back the hole in the python type system
that the string/bytes distinction was supposed to plug. That is not
ideal, but was the best solution of the alternatives I could come up
with. The options I considered were:
- make use of the type system to add type safety to the test suite: This
  required making a lot of changes to the test suite, since most of the
  strings would now become byte objects instead, and it was not even
  fully clear to me where to draw the line. One extreme solution would
  be to just use byte objects everywhere, as the protocol doesn't
  support non-ascii characters anyway. However, this appeared to be:
  a) weird, because most of the protocol actually deals with strings,
     but we would have to prefix everything with 'b'
  b) clunky, because the handling of the bytes objects is sufficiently
     different in PY2 and PY3 (e.g. b'a'[0] is a string in PY2, but an
     int in PY3).
- using the latin1 codec (which gives an identity transformation for the
  first 256 code points of unicode) instead of the custom
  bytes_to_string functions. This almost could work, but it was still
  slightly different between python 2 and 3, because in PY2 in would
  return a unicode object, which would then cause problems when
  combined with regular strings if it contained 8-bit chars.

With this in mind, I think the best solution for the time being is to
just coerce everything into the string type as early as possible, and
have things proceed indentically on both python versions. Once we stop
supporting python3, we can revisit the idea of using bytes objects more
prevasively.

Reviewers: davide, zturner, serge-sans-paille

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D58177

llvm-svn: 354106
lldb/packages/Python/lldbsuite/support/seven.py
lldb/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteModuleInfo.py
lldb/packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py
lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
lldb/packages/Python/lldbsuite/test/tools/lldb-server/socket_packet_pump.py