Repository navigation
Exposing more types to native modules #5641
Copy link
Copy link
Closed
Labels
py-coreRelates to py/ directory in sourceRelates to py/ directory in source
Description
I'm trying to expose the mp_type_int, mp_type_float and mp_type_bytes to native modules. I have done the following things:
- modified
mp_fun_table_tinnativeglue.hto add the types:
...
const mp_obj_type_t *type_type;
const mp_obj_type_t *type_int;
const mp_obj_type_t *type_float;
const mp_obj_type_t *type_str;
const mp_obj_type_t *type_bytes;
const mp_obj_type_t *type_list;
const mp_obj_type_t *type_dict;
const mp_obj_type_t *type_fun_builtin_0;
const mp_obj_type_t *type_fun_builtin_1;
const mp_obj_type_t *type_fun_builtin_2;
const mp_obj_type_t *type_fun_builtin_3;
const mp_obj_type_t *type_fun_builtin_var;
...
- modified
mp_fun_tableinnativeglue.cto set the pointer values:
...
&mp_type_type,
&mp_type_int,
&mp_type_float,
&mp_type_str,
&mp_type_bytes,
&mp_type_list,
&mp_type_dict,
&mp_type_fun_builtin_0,
&mp_type_fun_builtin_1,
&mp_type_fun_builtin_2,
&mp_type_fun_builtin_3,
&mp_type_fun_builtin_var,
...
- recompiled the micropython unix port.
Unfortunately I seem to be getting an odd error where the functions are no longer hooked up correctly, I suspect that this is because there is an offset in the exported function table somewhere which has not been updated, so mp_type_fun_builtin_1 is now mapped to mp_type_list.
==26922== Memcheck, a memory error detector
==26922== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==26922== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==26922== Command: ../../../ports/unix/micropython
==26922==
MicroPython v1.12-88-gae3fadbc3-dirty on 2020-02-13; linux version
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> import ucbor
>>> ucbor.loads(b'\x01')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'list' object isn't callable
>>>
I also noticed that in mpy_ld.py there is a section which specifically resolves some other type symbols. Adjusting this to also add my new types did not solve the problem unfortunately (and I'm not getting a linker error anyway...)
Does anyone know where the table is that I am not updating properly?
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
py-coreRelates to py/ directory in sourceRelates to py/ directory in source
Activity
dpgeorge commentedon Feb 14, 2020
You need to make sure the changes are reflected in this table: https://github.com/micropython/micropython/blob/master/tools/mpy_ld.py#L666-L682
jeremyherbert commentedon Feb 14, 2020
Yes, I've added the symbols to that (unfortunately it doesn't fix the issue, so I think I have a problem elsewhere).
I would have thought that without them I should hit the LinkError on line 704 anyway?
jeremyherbert commentedon Feb 14, 2020
Just some more notes for me to refer to later:
after building micropython with
DEBUG=1,paholeshows that the exported symbol table has the correct structure:pahole --reorganize -C _mp_fun_table_t micropythongivesAnd indeed the table is still lined up with the
mp_ld.pyoffset of 67 * 8 = mp_type_type.jeremyherbert commentedon Feb 14, 2020
modifying mp_ld.py to print out symbol offsets shows that
mp_type_fun_builtin_1is indeed being mapped to offset 576 in the native module, rather than the correct offset of 600.But in this process I actually just found my dumb mistake, see if you can spot it:
dpgeorge commentedon Feb 14, 2020
Ok, so you missed commas!
It might be a good idea to generate this table in
mpy_ld.pyautomatically (when that script runs) by parsingpy/nativeglue.h.jeremyherbert commentedon Feb 14, 2020
Ah, didn't see this in time. I just created a PR with all of the types from obj.h.
I'll need to think a bit about parsing, because from memory
pycparsingdoesn't like macros and micropython obviously uses them a lot.Merge pull request micropython#5641 from jepler/bitbangio-spi-write-s…