[Python-Dev] stuck with dlopen... (original) (raw)

Gregory P. Smith greg at krypto.org
Mon Jan 19 20:53:13 CET 2009

If you run your python.exe under gdb you should be able to set a future breakpoint on your _PyEval_EvalMiniFrameEx function and debug from there.

On Wed, Jan 14, 2009 at 8:28 PM, <skip at pobox.com> wrote:

I've recently been working on generating C functions on-the-fly which inline the C code necessary to implement the bytecode in a given Python function. For example, this bytecode: >>> dis.dis(f) 2 0 LOADFAST 0 (a) 3 LOADCONST 1 (1) 6 BINARYADD 7 RETURNVALUE is transformed into this rather boring bit of C code: #include "Python.h" #include "code.h" #include "frameobject.h" #include "eval.h" #include "opcode.h" #include "structmember.h" #include "opcodemini.h" PyObject * PyEvalEvalMiniFrameEx(PyFrameObject *f, int throwflag) { static int jitting = 1; PyEvalEvalFrameExPROLOG1(); co = f->fcode; PyEvalEvalFrameExPROLOG2(); oparg = 0; LOADFASTIMPL(oparg); oparg = 1; LOADCONSTIMPL(oparg); BINARYADDIMPL(); RETURNVALUEIMPL(); PyEvalEvalFrameExEPILOG(); } The PROLOG1, PROLOG2 and EPILOG macros are just chunks of code from PyEvalEvalFrameEx. I have the code compiling and linking, and dlopen and dlsym seem to work, returning apparently valid pointers, but when I try to call the function I get Program received signal EXCBADACCESS, Could not access memory. Reason: KERNPROTECTIONFAILURE at address: 0x0000000c 0x0058066d in PyEvalEvalMiniFrameEx (f=0x230d30, throwflag=0) at MwDLSf.c:17 Line 17 is the PROLOG1 macro. I presume it's probably barfed on the very first instruction. (This is all on an Intel Mac running Leopard BTW.) Here are the commands generated to compile and link the C code: _gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall _ _-Wstrict-prototypes -g -DPyBUILDCORE -DNDEBUG _ _-I/Users/skip/src/python/py3k-t/Include _ _-I/Users/skip/src/python/py3k-t -c dTd5cl.c _ -o /tmp/MwDLSf.o _gcc -L/opt/local/lib -bundle -undefined dynamiclookup -g _ _/tmp/dTd5cl.o -L/Users/skip/src/python/py3k-t -lpython3.1 _ -o /tmp/MwDLSf.so (It just uses the distutils compiler module to build .so files.) The .so file looks more-or-less ok: % otool -L /tmp/MwDLSf.so /tmp/MwDLSf.so: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.3) though nm doesn't show that any undefined Py* symbols so I suspect I'm not linking it correctly. The Python executable was built without --enable-shared. I've tried building with that config flag, but that just gives me fits during debugging because it always wants to find libpython in the installation directory even if I'm running python.exe from the build directory. Installing is a little tedious because it relies on a properly functioning interpreter. dlopen is called very simply: handle = dlopen(shared, RTLDNOW); I used RTLDNOW because that's what sys.getdlopenflags() returns. I'm not calling dlclose for the time being. I'm not exactly sure where I should go from here. I'd be more than happy to open an item in the issue tracker. I was hoping to get something a bit closer to working before doing that though. The failure to properly load the compiled function makes it pretty much impossble to debug the generated code beyond what the compiler can tell me. Any suggestions? Skip

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/greg%40krypto.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20090119/90499c53/attachment-0001.htm>

More information about the Python-Dev mailing list