labath added a comment.
lldb-server is used on architectures that don't have python (readily)
available, and it uses the same codebase as the rest of lldb. (Granted, it only
needs a small subset of that codebase, and this subset doesn't/shouldn't care
about python, but we aren't able to split o
jingham added a comment.
Note also, the vast majority of the uses of LLDB_DISABLE_PYTHON are related to
the requirement that we have Python to use any of the data formatter
facilities. Those uses shouldn't be necessary. All the scripted interpreters
should go through the generic ScriptInterpr
jingham added a comment.
It doesn't seem unreasonable to want to build lldb for smaller systems that
don't have Python available, and in fact we do that internally at Apple.
Actually, it DOES seem a little unreasonable to me because after all you can
just run the debugserver/lldb-server and con
zturner added a comment.
Side question, should we just kill the `LLDB_DISABLE_PYTHON=0` codepath? It
can be a headache to get LLDB linking with Python (particularly on Windows),
but it would be nice to be able to delete all the preprocessor stuff.
https://reviews.llvm.org/D53989
__
jingham added a comment.
So the deal is that we were relying on a summary formatter to print wchar_t
before, and now you have a format option that handles them as well? Do we need
both? Maybe the summary also handles wchar_t * strings?
As an aside, for reasons that are not entirely clear to me
zturner added a comment.
Update: It's because There was a problem with my `PYTHONPATH` and python was
getting disabled at CMake configure time. So I was effectively running with
`LLDB_DISABLE_PYTHON`. So basically it's only broke on the
`LLDB_DISABLE_PYTHON` codepath.
https://reviews.llvm.o
zturner added a comment.
No, but thanks for the pointer. Interestingly, it worked for me on my home
machine but not on my work machine, and I'm not sure what the difference
between the two is.
Clearly the test in lang/cpp/wchar_t is making it into
`lldb_private::formatters::WCharSummaryProvid
jingham added a comment.
There were a bunch of other tests testing wchar_t handling, all in:
lang/cpp/wchar_t
as well as some tests in:
functionalities/data-formatter/data-formatter-stl/libcxx/string/TestDataFormatterLibcxxString.py
Those tests weren't failed (except for the latter test, and t
zturner created this revision.
zturner added a reviewer: jingham.
char16, char32, and wchar_t were previously broken. If you had a simple
variable like `wchar_t x = L'1'` and wrote `p x` LLDB would output `(wchar_t) x
= 1\0`. This is because it was using `eFormatChar` with a size of 2. What w
