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

[Pavel Labath via lldb-dev]

On 30/10/2019 11:18, Kamil Rytarowski wrote:
> 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.
> 


Well, I was hoping that for someone intimately familiar with libedit 
(i.e., Christos) the difference in behavior would be obvious from just 
looking at that patch. :) But, of course, I can't make anyone do 
anything (nor I want to do that), so if fixing/figuring that out 
requires more time than you're willing to devote to that right now, then 
yes, I guess it means I or someone else will have to dive in and figure 
out what's wrong (eventually).

pl