← index #3445Issue #2209
Related · high · value 2.479
QUERY · ISSUE

freezing an .mpy with mpy-cross -s suffix = *.mpy results in frozen_mpy.c having a DOT prepended to "__lt_module_gt_"

openby adritiumopened 2017-11-17updated 2024-09-29
  1. Create empty main.py
  2. "../../mpy-cross/mpy-cross.exe" -o main.mpy -s main.**mpy** main.py
    Note the -s param suffix is .mpy, not the to-be-expected .py
  3. python "../../tools/mpy-tool.py" -f -q build\genhdr\qstrdefs.preprocessed.h main.mpy > frozen_mpy.c
    will result in a dot placed where it shouldn't be i.e. search for .__lt_module_gt_ in the below frozen_mpy.c (it's in 4 places)

I understand you'd want to have -s with .py usually and I wasn't trying to break mpy-cross. If for some reason mpy-cross -s *.mpy isn't allowed because it unnecessarily increases difficulty in mpy-tool, then mpy-cross should err out and simply not produce an .mpy

But the idea place to fix this is in mpy-tool.py.


#include "py/mpconfig.h"
#include "py/objint.h"
#include "py/objstr.h"
#include "py/emitglue.h"

#if MICROPY_OPT_CACHE_MAP_LOOKUP_IN_BYTECODE != 0
#error "incompatible MICROPY_OPT_CACHE_MAP_LOOKUP_IN_BYTECODE"
#endif

#if MICROPY_LONGINT_IMPL != 2
#error "incompatible MICROPY_LONGINT_IMPL"
#endif

#if MPZ_DIG_SIZE != 16
#error "incompatible MPZ_DIG_SIZE"
#endif

#if MICROPY_PY_BUILTINS_FLOAT
typedef struct _mp_obj_float_t {
    mp_obj_base_t base;
    mp_float_t value;
} mp_obj_float_t;
#endif

#if MICROPY_PY_BUILTINS_COMPLEX
typedef struct _mp_obj_complex_t {
    mp_obj_base_t base;
    mp_float_t real;
    mp_float_t imag;
} mp_obj_complex_t;
#endif

enum {
    MP_QSTR_main_dot_mpy = MP_QSTRnumber_of,
};

extern const qstr_pool_t mp_qstr_const_pool;
const qstr_pool_t mp_qstr_frozen_const_pool = {
    (qstr_pool_t*)&mp_qstr_const_pool, // previous pool
    MP_QSTRnumber_of, // previous pool size
    1, // allocated entries
    1, // used entries
    {
        (const byte*)"\xc4\x08" "main.mpy",
    },
};

// frozen bytecode for file main.mpy, scope main._<module>
STATIC const byte bytecode_data_main.__lt_module_gt_[16] = {
    0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x07,
    MP_QSTR__lt_module_gt_ & 0xff, MP_QSTR__lt_module_gt_ >> 8,
    MP_QSTR_main_dot_mpy & 0xff, MP_QSTR_main_dot_mpy >> 8,
    0x00, 0x00, 0xff,
    0x11, 
    0x5b, 
};
const mp_raw_code_t raw_code_main.__lt_module_gt_ = {
    .kind = MP_CODE_BYTECODE,
    .scope_flags = 0x00,
    .n_pos_args = 0,
    .data.u_byte = {
        .bytecode = bytecode_data_main.__lt_module_gt_,
        .const_table = NULL,
        #if MICROPY_PERSISTENT_CODE_SAVE
        .bc_len = 16,
        .n_obj = 0,
        .n_raw_code = 0,
        #endif
    },
};

const char mp_frozen_mpy_names[] = {
"main.mpy\0"
"\0"};
const mp_raw_code_t *const mp_frozen_mpy_content[] = {
    &raw_code_main.__lt_module_gt_,
};

CANDIDATE · ISSUE

mpy-cross creates corrupt .mpy's on windows

closedby ghsebopened 2016-06-30updated 2016-07-22

I try to use frozen bytecode in stmhal in a windows/mingw environment. After compiling a python script to micropython bytecode with mpy-cross.exe i get a .mpy file as expected. If i then apply the mpy-tool.py on the .mpy file it raises an IndexError:

Creating build-STM32L476DISC/frozen_mpy.c
python3.5 ../tools/mpy-tool.py -f -q build-STM32L476DISC/genhdr/qstrdefs.preprocessed.h build-STM32L476DISC/freeze/test_script.mpy > build-STM32L476DISC/frozen_mpy.c
Traceback (most recent call last):
...
File "../tools/mpy-tool.py", line 357, in read_uint
b = bytes_cons(f.read(1))[0]
IndexError: index out of range
Makefile:301: recipe for target 'build-STM32L476DISC/frozen_mpy.c' failed
mingw32-make: *** [build-STM32L476DISC/frozen_mpy.c] Error 1
mingw32-make: *** Deleting file 'build-STM32L476DISC/frozen_mpy.c'

When i compared the bytecode that is generated in linux environments to the bytecode in windows environment the bytecode differs when it comes to a newline character in the bytecode (0xa). It seems that when the bytecode is generated by mpy-cross it prints out a newline (0xa) character somewhere and this is resolved to a linefeed-only in linux and to a carriage return (0xd) + linefeed (0xa) in windows. If the additional carriage return is removed freezing works.

I think the additional carriage return is not comming from the input python scripts, because in my windows environment i already tried linux encoded line endings and mpy-cross nevertheless failed.

Simple python script that produces the error (with windows newlines, apart from others that i tried):
test_script_class.py.txt

Resulting .mpy on windows
test_script_class_win.mpy.txt

Resulting .mpy on linux
test_script_class_linux.mpy.txt

Until now i could not figure out where the problem comes from.

br,
Sebastian

Keyboard

j / / n
next pair
k / / p
previous pair
1 / / h
show query pane
2 / / l
show candidate pane
c
copy suggested comment
r
toggle reasoning
g i
go to index
?
show this help
esc
close overlays

press ? or esc to close

copied