[lldb-dev] issue with lldb9 and python3.5

[Kamil Rytarowski via lldb-dev]

On 30.10.2019 11:06, Pavel Labath wrote:
> On 29/10/2019 21:40, Christos Zoulas wrote:
>> On Oct 29,  6:54pm, pavel at labath.sk (Pavel Labath) wrote:
>> -- Subject: Re: [lldb-dev] issue with lldb9 and python3.5
>>
>> | On 29/10/2019 09:31, Serge Guelton via lldb-dev wrote:
>> | > On Mon, Oct 28, 2019 at 10:09:53AM -0700, Adrian McCarthy wrote:
>> | >> +1 Yes, for Windows, I'd be happy if we said Python 3.6+.
>> | >
>> | > I investigated the bug yesterday, and filled some of my
>> discoveries in
>> | >
>> | >      https://bugs.llvm.org/show_bug.cgi?id=43830
>> | >
>> | > TLDR: libpython uses libreadline and lldb uses libedit, and that's
>> a mess.
>> |
>> | Hey Christos,
>> |
>> | could I bother you to take a look at this python PR
>> | <https://github.com/python/cpython/pull/16986>, and the related lldb
>> bug
>> | <https://bugs.llvm.org/show_bug.cgi?id=43830>?
>> |
>> | The executive summary is that there is an incompatibility between
>> | readline and its libedit emulation, which python needs to work around.
>> | Is there any way this can be fixed in libedit?
>> |
>> | I guess the presence of the workaround will make the fix tricky,
>> because
>> | then the workaround will be wrong for the "fixed" libedit, but it's
>> | still probably worth it to try to resolve this somehow.
>> |
>> | WDYT?
>>
>> I don't know what I have to do here. Can someone explain to me what the
>> issue is?
> 
> I haven't dug into this (maybe Serge can explain in more detail), but I
> think this comment (Modules/readline.c in python sources) gives a
> general overview of the problem. Ignore the "On OSX" part, the same
> should apply to any OS.
> 
> /*
>  * It is possible to link the readline module to the readline
>  * emulation library of editline/libedit.
>  *
>  * On OSX this emulation library is not 100% API compatible
>  * with the "real" readline and cannot be detected at compile-time,
>  * hence we use a runtime check to detect if we're using libedit
>  *
>  * Currently there is one known API incompatibility:
>  * - 'get_history' has a 1-based index with GNU readline, and a 0-based
>  *   index with older versions of libedit's emulation.
>  * - Note that replace_history and remove_history use a 0-based index
>  *   with both implementations.
>  */
> 
> Furthermore, you can probably look at every instance of
> if(using_libedit_emulation) in that file (or via this link
> <https://github.com/python/cpython/pull/16986/commits/3f325105d21af7cb8fd85de46af439f8579e6d7a#diff-41a8081584647e8f0451b4937c11ce71L53>),
> as each one indicates a workaround for some libedit incompatibility. It
> looks like not all of them are still relevant, as it seems some of them
> are there just for the sake of old libedit bugs which have since been
> fixed, but it looks like at least some of them are. Serge, can you tell
> what exactly was the problem which caused the crash?
> 
> pl

Is this a packaging issue?

There are good reasons to use libedit as a gnu readline drop in
replacement. The most important one is certainly saner licensing state
as gnu readline is GPLv3 and it makes it incompatible with at least
GPLv2 users (there are users that pick old gnureadline GPLv2 around).

If there are known incompatibilities, I think (not speaking on behalf of
Christos) it would be best to contribute patches with rationale. Generic
call for compatibility might not work well.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20191030/9d45edf4/attachment.sig>