This abstracts the interface for generation of the strip command
line, by naming the desired actions instead of directly setting the
command parameters, which then opens up for other binary tool sets
which may require different arguments to achieve the desired result.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
This abstracts the interface for generation of the readelf command
line, by naming the desired actions instead of directly setting the
command parameters, which then opens up for other binary tool sets
which may require different arguments to achieve the desired result.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
This abstracts the interface for generation of the objdump command
line, by naming the desired actions instead of directly setting the
command parameters, which then opens up for other binary tool sets
which may require different arguments to achieve the desired result.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
This abstracts the interface for generation of the objcopy command
line, by naming the desired actions instead of directly setting the
command parameters, which then opens up for other binary tool sets
which may require different arguments to achieve the desired result.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
The method for getting a memory usage report printed during build, is
based on a GNU linker (ld) option flag, and thus is not necessarily
supported by other toolchain binary tools.
The introduced cmake macro allows for a given toolchain to specify how
the memory usage report is to be generated, and whether the command for
generation, if any, is to be added to the post_build_commands and the
post_build_byproducts lists of the top level CMakeLists.txt
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
This forms the foundation for the abstraction of the binary tools,
where the following steps are taken:
- Move binary tool resolving, such as objcopy, objdump, readelf and
so forth, out of compiler definitions and place in a dedicated binary
tools folder with the binary tools supplier as subfolder, similar to
the compiler and linker directories.
- Create binary tool sets, gnu, host-gnu and llvm.
- Each toolchain selects the required set of binary tools by setting
BINTOOLS via its generic.cmake as it also does for compiler and linker.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
Danny Oerndrup