Files
llvm/lldb/scripts/Python/modules/readline/readline.cpp

88 lines
2.5 KiB
C++
Raw Normal View History

// NOTE: Since Python may define some pre-processor definitions which affect the
// standard headers on some systems, you must include Python.h before any
// standard headers are included.
Suppress python readline module under Linux to fix a seg fault. Bug fix for pr18841: http://llvm.org/bugs/show_bug.cgi?id=18841 This change creates a stub Python readline.so module that does almost nothing. Its whole purpose is to prevent Python from loading the real module, something it does during the embedded Python interpreter's initialization sequence (and way before lldb ever requests it within embedded_interpreter.py). On Ubuntu 12.04 and 13.10 x86_64, and in the Python 2.7.6 tree, the stock Python readline module links against the GNU readline library. This appears to be the case on all Pythons except where __APPLE__ is defined. LLDB now requires linking against the libedit library. Something about having both libedit.so and libreadline.so linked into the same process space is causing the Python readline.so to trigger a NULL memory access. I have put in a separate patch to python.org. This suppression of embedded interpreter readline support can be removed if at least any one of the following happens: 1. The stock python distribution accepts a patch similar to what I submitted to Python 2.7.6's Modules/readline.c file. 2. The stock python distribution implements Modules/readline.c in terms of libedit's readline compatibility mode (i.e. essentially compiles it the way __APPLE__ compiles that module) under Linux. 3. a clean-room implementation of the python readline module is implemented against libedit (either readline compatibility mode or native libedit). This could be implemented within the readline.cpp file that this change introduces. It cannot be a fork of python's readline.c module due to llvm licensing. The net effect of this change on Linux is that the embedded python's readline support will not exist. llvm-svn: 202243
2014-02-26 07:39:20 +00:00
#include "Python.h"
#include <stdio.h>
#ifndef LLDB_DISABLE_LIBEDIT
#include <editline/readline.h>
#endif
// Simple implementation of the Python readline module using libedit.
// In the event that libedit is excluded from the build, this turns
// back into a null implementation that blocks the module from pulling
// in the GNU readline shared lib, which causes linkage confusion when
// both readline and libedit's readline compatibility symbols collide.
//
// Currently it only installs a PyOS_ReadlineFunctionPointer, without
// implementing any of the readline module methods. This is meant to
// work around LLVM pr18841 to avoid seg faults in the stock Python
// readline.so linked against GNU readline.
Suppress python readline module under Linux to fix a seg fault. Bug fix for pr18841: http://llvm.org/bugs/show_bug.cgi?id=18841 This change creates a stub Python readline.so module that does almost nothing. Its whole purpose is to prevent Python from loading the real module, something it does during the embedded Python interpreter's initialization sequence (and way before lldb ever requests it within embedded_interpreter.py). On Ubuntu 12.04 and 13.10 x86_64, and in the Python 2.7.6 tree, the stock Python readline module links against the GNU readline library. This appears to be the case on all Pythons except where __APPLE__ is defined. LLDB now requires linking against the libedit library. Something about having both libedit.so and libreadline.so linked into the same process space is causing the Python readline.so to trigger a NULL memory access. I have put in a separate patch to python.org. This suppression of embedded interpreter readline support can be removed if at least any one of the following happens: 1. The stock python distribution accepts a patch similar to what I submitted to Python 2.7.6's Modules/readline.c file. 2. The stock python distribution implements Modules/readline.c in terms of libedit's readline compatibility mode (i.e. essentially compiles it the way __APPLE__ compiles that module) under Linux. 3. a clean-room implementation of the python readline module is implemented against libedit (either readline compatibility mode or native libedit). This could be implemented within the readline.cpp file that this change introduces. It cannot be a fork of python's readline.c module due to llvm licensing. The net effect of this change on Linux is that the embedded python's readline support will not exist. llvm-svn: 202243
2014-02-26 07:39:20 +00:00
#ifndef LLDB_DISABLE_LIBEDIT
PyDoc_STRVAR(moduleDocumentation,
"Simple readline module implementation based on libedit.");
#else
PyDoc_STRVAR(moduleDocumentation,
"Stub module meant to avoid linking GNU readline.");
#endif
#if PY_MAJOR_VERSION >= 3
static struct PyModuleDef readline_module = {
PyModuleDef_HEAD_INIT, // m_base
"readline", // m_name
moduleDocumentation, // m_doc
-1, // m_size
nullptr, // m_methods
nullptr, // m_reload
nullptr, // m_traverse
nullptr, // m_clear
nullptr, // m_free
};
#else
static struct PyMethodDef moduleMethods[] = {{nullptr, nullptr, 0, nullptr}};
#endif
#ifndef LLDB_DISABLE_LIBEDIT
static char *
#if PY_MAJOR_VERSION >= 3
simple_readline(FILE *stdin, FILE *stdout, const char *prompt)
#else
simple_readline(FILE *stdin, FILE *stdout, char *prompt)
#endif
{
rl_instream = stdin;
rl_outstream = stdout;
char *line = readline(prompt);
if (!line) {
char *ret = (char *)PyMem_Malloc(1);
if (ret != NULL)
*ret = '\0';
return ret;
}
if (*line)
add_history(line);
int n = strlen(line);
char *ret = (char *)PyMem_Malloc(n + 2);
strncpy(ret, line, n);
free(line);
ret[n] = '\n';
ret[n + 1] = '\0';
return ret;
}
#endif
Suppress python readline module under Linux to fix a seg fault. Bug fix for pr18841: http://llvm.org/bugs/show_bug.cgi?id=18841 This change creates a stub Python readline.so module that does almost nothing. Its whole purpose is to prevent Python from loading the real module, something it does during the embedded Python interpreter's initialization sequence (and way before lldb ever requests it within embedded_interpreter.py). On Ubuntu 12.04 and 13.10 x86_64, and in the Python 2.7.6 tree, the stock Python readline module links against the GNU readline library. This appears to be the case on all Pythons except where __APPLE__ is defined. LLDB now requires linking against the libedit library. Something about having both libedit.so and libreadline.so linked into the same process space is causing the Python readline.so to trigger a NULL memory access. I have put in a separate patch to python.org. This suppression of embedded interpreter readline support can be removed if at least any one of the following happens: 1. The stock python distribution accepts a patch similar to what I submitted to Python 2.7.6's Modules/readline.c file. 2. The stock python distribution implements Modules/readline.c in terms of libedit's readline compatibility mode (i.e. essentially compiles it the way __APPLE__ compiles that module) under Linux. 3. a clean-room implementation of the python readline module is implemented against libedit (either readline compatibility mode or native libedit). This could be implemented within the readline.cpp file that this change introduces. It cannot be a fork of python's readline.c module due to llvm licensing. The net effect of this change on Linux is that the embedded python's readline support will not exist. llvm-svn: 202243
2014-02-26 07:39:20 +00:00
PyMODINIT_FUNC initreadline(void) {
#ifndef LLDB_DISABLE_LIBEDIT
PyOS_ReadlineFunctionPointer = simple_readline;
#endif
#if PY_MAJOR_VERSION >= 3
return PyModule_Create(&readline_module);
#else
Py_InitModule4("readline", moduleMethods, moduleDocumentation,
static_cast<PyObject *>(NULL), PYTHON_API_VERSION);
#endif
Suppress python readline module under Linux to fix a seg fault. Bug fix for pr18841: http://llvm.org/bugs/show_bug.cgi?id=18841 This change creates a stub Python readline.so module that does almost nothing. Its whole purpose is to prevent Python from loading the real module, something it does during the embedded Python interpreter's initialization sequence (and way before lldb ever requests it within embedded_interpreter.py). On Ubuntu 12.04 and 13.10 x86_64, and in the Python 2.7.6 tree, the stock Python readline module links against the GNU readline library. This appears to be the case on all Pythons except where __APPLE__ is defined. LLDB now requires linking against the libedit library. Something about having both libedit.so and libreadline.so linked into the same process space is causing the Python readline.so to trigger a NULL memory access. I have put in a separate patch to python.org. This suppression of embedded interpreter readline support can be removed if at least any one of the following happens: 1. The stock python distribution accepts a patch similar to what I submitted to Python 2.7.6's Modules/readline.c file. 2. The stock python distribution implements Modules/readline.c in terms of libedit's readline compatibility mode (i.e. essentially compiles it the way __APPLE__ compiles that module) under Linux. 3. a clean-room implementation of the python readline module is implemented against libedit (either readline compatibility mode or native libedit). This could be implemented within the readline.cpp file that this change introduces. It cannot be a fork of python's readline.c module due to llvm licensing. The net effect of this change on Linux is that the embedded python's readline support will not exist. llvm-svn: 202243
2014-02-26 07:39:20 +00:00
}