Kamil Rytarowski <n...@gmx.com> wrote on 29.05.2017 18:10:36:
> Do you offer shell account? I don't have Linux and/or s390x to debug it.
Sorry, this is on an internal IBM machine ... I don't have a publically
accessible machine to reproduce this on at the moment.
I managed to debug a bit myself, and I think the problem is this:
After your change, this routine:
int Editline::GetCharacter(EditLineGetCharType *c) {
now has a "wchar_t *" argument, and stores the output character
as a 4-byte wide character on Linux.
However, the caller of this routine does this (this is the Fedora 24
version of libedit - libedit-3.1-14.20150325cvs.fc24.src.rpm):
num_read = (*el->el_read.read_char)(el, cp);
if (num_read < 0)
el->el_errno = errno;
#ifdef WIDECHAR
if (el->el_flags & NARROW_READ)
*cp = *(char *)(void *)cp;
#endif
In my case, the (el->el_flags & NARROW_READ) is true, so it
accesses the wchar_t as a char and extends that to a wchar_t.
On a little-endian machine, this would be a no-op, but on a
big-endian machine, this basically always set the character
to 0.
Now, the question is why is the NARROW_READ flag set. It
appears this is the case because the EL_GETCFN call that
installs the callback used el_set, not el_wset (that is
what triggers setting vs. clearing NARROW_READ).
The LLDB code does *appear* to use el_wset:
el_wset(m_editline, EL_GETCFN, (EditlineGetCharCallbackType)([](
EditLine *editline,
EditLineGetCharType *c) {
return Editline::InstanceFor(editline)->GetCharacter(c);
}));
but that's not actually true, because of:
#if LLDB_EDITLINE_USE_WCHAR
[...]
#else
[...]
#define el_wset el_set
[...]
#endif // #if LLDB_EDITLINE_USE_WCHAR
at the top of the file. Note that on Linux, it appears
LLDB_EDITLINE_USE_WCHAR is unconditionally set to 0:
#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__NetBSD__) ||
\
defined(__OpenBSD__)
#define LLDB_EDITLINE_USE_WCHAR 1
#include <codecvt>
#else
#define LLDB_EDITLINE_USE_WCHAR 0
#endif
So in general, it looks like the bug is that LLDB on Linux
always installs the EL_GETFCN callback using el_set, which
causes libedit to assume it actually takes a char *
argument, but LLDB now defines the routine as taking a
wchar_t * argument, which causes the character to be always
read as 0 on all big-endian Linux systems.
Is this enough information for you to fix the problem?
If you'd like me to do more debugging, please let me know.
Bye,
Ulrich
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
