freezing an .mpy with mpy-cross -s suffix = *.mpy results in frozen_mpy.c having a DOT prepended to "__lt_module_gt_"
- Create empty
main.py "../../mpy-cross/mpy-cross.exe" -o main.mpy -s main.**mpy** main.py
Note the-sparam suffix is .mpy, not the to-be-expected .pypython "../../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 belowfrozen_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_,
};
tools/mpy-tool.py: Clean up escaped compiled module name.
Summary
This PR lets "mpy-tool.py" filter unwanted characters that may end up in the compiled module name, even after the first encoding pass.
Certain characters are already ASCII-safe but cannot appear in a C identifier (eg. dots, dashes, etc.). Those characters, when appearing in a module name, won't be escaped and will be placed in the output C source code template when freezing files - leading to an invalid source file.
Now the code, after the first character encoding pass, will pre-process the compiled module name to use when filling out the C source code template. Every character that is not expected to be part of a C identifier will be replaced with an underscore.
This closes #3445.
Testing
A Python file was frozen with a custom module name containing characters that cannot be part of a C identifier, and the generated C file was compiled to make sure all generated identifiers are compliant:
$ cd ports/unix
$ make
$ printf "class Hello:\n def __init__(self):\n pass\n" > test.py
$ ../../mpy-cross/build/mpy-cross -o test.mpy -s "test.mpy" test.py
$ ../../tools/mpy-tool.py -f -q build-standard/genhdr/qstrdefs.preprocessed.h test.mpy > frozen.c
$ gcc -I. -I../.. -Ivariants/standard -Ibuild-standard -DMPZ_DIG_SIZE=16 -c frozen.c
$ size frozen.o
text data bss dec hex filename
155 176 0 331 14b frozen.o
Trade-offs and Alternatives
This PR does not help recovering from cases where the module gets named with incompatible names (eg. starting with a digit), but that wouldn't have worked in the first place.
Generative AI
I did not use generative AI tools when creating this PR.