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, pa...@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
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
