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, <s...@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 LOAD_FAST 0 (a)
> 3 LOAD_CONST 1 (1)
> 6 BINARY_ADD
> 7 RETURN_VALUE
>
> 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 "opcode_mini.h"
>
> PyObject *
> _PyEval_EvalMiniFrameEx(PyFrameObject *f, int throwflag)
> {
>
> static int jitting = 1;
>
> PyEval_EvalFrameEx_PROLOG1();
> co = f->f_code;
> PyEval_EvalFrameEx_PROLOG2();
>
> oparg = 0;
> LOAD_FAST_IMPL(oparg);
> oparg = 1;
> LOAD_CONST_IMPL(oparg);
> BINARY_ADD_IMPL();
> RETURN_VALUE_IMPL();
>
> PyEval_EvalFrameEx_EPILOG();
> }
>
> The PROLOG1, PROLOG2 and EPILOG macros are just chunks of code from
> PyEval_EvalFrameEx.
>
> 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 EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000c
> 0x0058066d in _PyEval_EvalMiniFrameEx (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 -DPy_BUILD_CORE -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 dynamic_lookup -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, RTLD_NOW);
>
> I used RTLD_NOW 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@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
