13 Commits

Author	SHA1	Message	Date
Alessandro Gatti	b87d73f2e9	tools/mpy_ld.py: Write architecture flags to output natmod if needed. ... This commit lets "tools/mpy_ld.py" store architecture flags in generated MPY files if explicitly requested, like "mpy-cross" does. To achieve this, a new command-line option ("--arch-flags") was added to receive the architecture flags value, accepting the same arguments' format as "mpy-cross", and performing the same input validation. The rest of the MPY toolchain was also modified to let the user pass the arch flags to standard native module makefiles. Given that there's already a well-established "ARCH" argument, "ARCH_FLAGS" was chosen to pass the optional flags to "mpy_ld.py". Finally, documentation was updated to mention the new variable. Signed-off-by: Alessandro Gatti <a.gatti@frob.it>	2026-01-11 09:22:13 +01:00
Alessandro Gatti	e939d3ec76	tools/mpy_ld.py: Add RV64 natmod support. ... This commit adds the ability to compile native modules for the RV64 platform, using "rv64imc" as its architecture name (eg. "make ARCH=rv64imc" should build a RV64 natmod). The rest of 64-bits relocations needed to build a native module are now implemented, and all sample native modules build without errors or warnings. The same Picolibc caveats on RV32 also apply on RV64, thus the documentation was updated accordingly. RV64 native modules are also built as part of the CI process, but not yet executed as the QEMU port is not yet able to load and run them. Signed-off-by: Alessandro Gatti <a.gatti@frob.it>	2025-12-30 18:18:42 +01:00
Alessandro Gatti	e993f53877	docs/develop/natmod: Add notes on Picolibc and natmods. ... This commit adds some documentation on what are the limitations of using Picolibc as a standard C library for native modules. This also contains a reference to the "errno" issue when building natmods on RV32 that the PR this commit is part of, as it is not obvious how to approach this issue when encountered for the first time. Signed-off-by: Alessandro Gatti <a.gatti@frob.it>	2025-07-20 23:03:40 +10:00
Alessandro Gatti	bf2005de9e	tools/mpy_ld.py: Resolve fixed-address symbols if requested. ... This commit lets mpy_ld.py resolve symbols not only from the object files involved in the linking process, or from compiler-supplied static libraries, but also from a list of symbols referenced by an absolute address (usually provided by the system's ROM). This is needed for ESP8266 targets as some C stdlib functions are provided by the MCU's own ROM code to reduce the final code footprint, and therefore those functions' implementation was removed from the compiler's support libraries. This means that unless `LINK_RUNTIME` is set (which lets tooling look at more libraries to resolve symbols) the build process will fail as tooling is unaware of the ROM symbols' existence. With this change, fixed-address symbols can be exposed to the symbol resolution step when performing natmod linking. If there are symbols coming in from a fixed-address symbols list and internal code or external libraries, the fixed-address symbol address will take precedence in all cases. Although this is - in theory - also working for the whole range of ESP32 MCUs, testing is currently limited to Xtensa processors and the example natmods' makefiles only make use of this commit's changes for the ESP8266 target. Natmod builds can set the MPY_EXTERN_SYM_FILE variable pointing to a linkerscript file containing a series of symbols (weak or strong) at a fixed address; these symbols will then be used by the MicroPython linker when packaging the natmod. If a different natmod build method is used (eg. custom CMake scripts), `tools/mpy_ld.py` can now accept a command line parameter called `--externs` (or its short variant `-e`) that contains the path of a linkerscript file with the fixed-address symbols to use when performing the linking process. The linkerscript file parser can handle a very limited subset of binutils's linkerscript syntax, namely just block comments, strong symbols, and weak symbols. Each symbol must be in its own line for the parser to succeed, empty lines or comment blocks are skipped. For an example of what this parser was meant to handle, you can look at `ports/esp8266/boards/eagle.rom.addr.v6.ld` and follow its format. The natmod developer documentation is also updated to reflect the new command line argument accepted by `mpy_ld.py` and the use cases for the changes introduced by this commit. Signed-off-by: Alessandro Gatti <a.gatti@frob.it>	2025-06-04 22:35:39 +10:00
Volodymyr Shymanskyy	51976110e2	tools/mpy_ld.py: Allow linking static libraries. ... This commit introduces an additional symbol resolution mechanism to the natmod linking process. This allows the build scripts to look for required symbols into selected libraries that are provided by the compiler installation (libgcc and libm at the moment). For example, using soft-float code in natmods, whilst technically possible, was not an easy process and required some additional work to pull it off. With this addition all the manual (and error-prone) operations have been automated and folded into `tools/mpy_ld.py`. Both newlib and picolibc toolchains are supported, albeit the latter may require a bit of extra configuration depending on the environment the build process runs on. Picolibc's soft-float functions aren't in libm - in fact the shipped libm is nothing but a stub - but they are inside libc. This is usually not a problem as these changes cater for that configuration quirk, but on certain compilers the include paths used to find libraries in may not be updated to take Picolibc's library directory into account. The bare metal RISC-V compiler shipped with the CI OS image (GCC 10.2.0 on Ubuntu 22.04LTS) happens to exhibit this very problem. To work around that for CI builds, the Picolibc libraries' path is hardcoded in the Makefile directives used by the linker, but this can be changed by setting the PICOLIBC_ROOT environment library when building natmods. Signed-off-by: Volodymyr Shymanskyy <vshymanskyi@gmail.com> Co-authored-by: Alessandro Gatti <a.gatti@frob.it>	2025-03-17 13:03:27 +11:00
Alessandro Gatti	6760e00817	tools/mpy_ld.py: Add native modules support for RV32 code. ... This commit adds support for RV32IMC native modules, as in embedding native code into a self-contained MPY module and and make its exported functions available to the MicroPython environment. Signed-off-by: Alessandro Gatti <a.gatti@frob.it>	2024-12-23 10:02:20 +11:00
Angus Gratton	decf8e6a8b	all: Remove the "STATIC" macro and just use "static" instead. ... The STATIC macro was introduced a very long time ago in commit d5df6cd44a. The original reason for this was to have the option to define it to nothing so that all static functions become global functions and therefore visible to certain debug tools, so one could do function size comparison and other things. This STATIC feature is rarely (if ever) used. And with the use of LTO and heavy inline optimisation, analysing the size of individual functions when they are not static is not a good representation of the size of code when fully optimised. So the macro does not have much use and it's simpler to just remove it. Then you know exactly what it's doing. For example, newcomers don't have to learn what the STATIC macro is and why it exists. Reading the code is also less "loud" with a lowercase static. One other minor point in favour of removing it, is that it stops bugs with `STATIC inline`, which should always be `static inline`. Methodology for this commit was: 1) git ls-files | egrep '\.[ch]$' | \ xargs sed -Ei "s/(^| )STATIC($| )/\1static\2/" 2) Do some manual cleanup in the diff by searching for the word STATIC in comments and changing those back. 3) "git-grep STATIC docs/", manually fixed those cases. 4) "rg -t python STATIC", manually fixed codegen lines that used STATIC. This work was funded through GitHub Sponsors. Signed-off-by: Angus Gratton <angus@redyak.com.au>	2024-03-07 14:20:42 +11:00
Damien George	c1b9d2259e	py/dynruntime.mk: Add basic support for armv6m architecture. ... The examples/natmod features0 and features1 examples now build and run on ARMv6-M platforms. More complicated examples are not yet supported because the compiler emits references to built-in functions like __aeabi_uidiv. Signed-off-by: Damien George <damien@micropython.org>	2022-05-23 23:01:25 +10:00
Samuelson	407df82f81	docs/develop/natmod: Fix a small typo, con->can.	2021-01-30 15:20:44 +11:00
Damien George	c8ade2bd7f	docs/develop: Add notes on prerequisite tools for building native .mpy. ... Signed-off-by: Damien George <damien@micropython.org>	2020-09-25 12:25:29 +10:00
Damien George	cae77daf00	docs/develop: Fix module/source name in Makefile of native example.	2020-05-16 15:00:46 +10:00
Thorsten von Eicken	be92aacba3	docs/develop: Detail how to add symbols to mp_fun_table for native mods.	2020-02-16 00:04:25 +11:00
Damien George	8449e41818	docs/develop: Add documentation on how to build native .mpy modules.	2019-12-19 17:07:53 +11:00