xiaoxiang781216 commented on code in PR #19940: URL: https://github.com/apache/nuttx/pull/19940#discussion_r3876986882
########## Documentation/components/tools/fdpic.rst: ########## @@ -0,0 +1,111 @@ +===================================== +fdpic: FDPIC module build tooling +===================================== + +``tools/fdpic`` is everything needed to build an FDPIC module out of tree. A +module is an ELF shared object whose read-only segment the target maps straight +out of flash and executes in place, while its writable segment is copied to RAM +once per running instance. It links against nothing: libc and everything else +are imported from the firmware's exported symbol table at load time. + +These are host tools only. ``apps/examples/fdpicxip`` uses them to rebuild its +committed module blobs, which is what they are in the tree for. The loader that +runs such a module is proposed separately; until it is in, a module built here +has nothing in NuttX to load it. + +Contents +======== + +============================ ================================================== +File Purpose +============================ ================================================== +``nuttx-fdpic.mk`` The module build itself; include it from a + two-line makefile +``fdpic-verify.sh`` Checks a built module's imports resolve against + the firmware +``nuttx-exports.sh`` Turns ``libs/libc/exec_symtab.c`` into a symbol + list +``fdpic-embed.py`` Turns a built module into a C header, for carrying + one inside an image +``build-binutils.sh`` Builds the ``arm-uclinuxfdpiceabi`` binutils, the + one from-source dependency +``crt0.c`` The module start-up file, linked into every + module that is entered +``init-array.ld`` Names the bounds of ``.init_array`` for it +============================ ================================================== + +Building a module +================= + +A whole module is three lines of makefile beside the source. Taking +``apps/examples/fdpicxip/modules/qsorter.c``, which is a module in its own +right, as the source: + +.. code:: makefile + + MODULE = qsorter + SRCS = qsorter.c + + include /path/to/nuttx/tools/fdpic/nuttx-fdpic.mk Review Comment: why do we need special script to build fdpic elf? please integrate fdpic into the normal elf build proces. basically once CONFIG_FDPIC and MODULE=y, all generated elf will become FDPIC. ########## Documentation/components/tools/fdpic.rst: ########## @@ -0,0 +1,111 @@ +===================================== +fdpic: FDPIC module build tooling +===================================== + +``tools/fdpic`` is everything needed to build an FDPIC module out of tree. A +module is an ELF shared object whose read-only segment the target maps straight +out of flash and executes in place, while its writable segment is copied to RAM +once per running instance. It links against nothing: libc and everything else +are imported from the firmware's exported symbol table at load time. + +These are host tools only. ``apps/examples/fdpicxip`` uses them to rebuild its +committed module blobs, which is what they are in the tree for. The loader that +runs such a module is proposed separately; until it is in, a module built here +has nothing in NuttX to load it. + +Contents +======== + +============================ ================================================== +File Purpose +============================ ================================================== +``nuttx-fdpic.mk`` The module build itself; include it from a + two-line makefile +``fdpic-verify.sh`` Checks a built module's imports resolve against + the firmware +``nuttx-exports.sh`` Turns ``libs/libc/exec_symtab.c`` into a symbol + list +``fdpic-embed.py`` Turns a built module into a C header, for carrying + one inside an image +``build-binutils.sh`` Builds the ``arm-uclinuxfdpiceabi`` binutils, the + one from-source dependency +``crt0.c`` The module start-up file, linked into every + module that is entered +``init-array.ld`` Names the bounds of ``.init_array`` for it +============================ ================================================== + +Building a module +================= + +A whole module is three lines of makefile beside the source. Taking +``apps/examples/fdpicxip/modules/qsorter.c``, which is a module in its own +right, as the source: + +.. code:: makefile + + MODULE = qsorter + SRCS = qsorter.c + + include /path/to/nuttx/tools/fdpic/nuttx-fdpic.mk + +Then: + +.. code:: console + + $ make NUTTX_DIR=/path/to/nuttx + CC crt0.c + CC qsorter.c + LD qsorter.fdpic + OK qsorter.fdpic: FDPIC, entry 0x2a1, 4 imports resolved + +``NUTTX_DIR`` has to be a configured, built tree: the compile needs its headers +and the verify step needs the export table generated into +``libs/libc/exec_symtab.c``. + +Toolchain +========= + +Two toolchains are involved. The stock ``arm-none-eabi`` compiler does the +compiling -- it emits perfectly good FDPIC objects for both C and C++ -- and +``arm-uclinuxfdpiceabi`` **binutils** does the linking, because Review Comment: need integrate into ELF link make ########## tools/fdpic/build-binutils.sh: ########## @@ -0,0 +1,84 @@ +#!/bin/bash +############################################################################ +# tools/fdpic/build-binutils.sh +# +# SPDX-License-Identifier: Apache-2.0 +# +# Licensed to the Apache Software Foundation (ASF) under one or more +# contributor license agreements. See the NOTICE file distributed with +# this work for additional information regarding copyright ownership. The +# ASF licenses this file to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance with the +# License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT +# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the +# License for the specific language governing permissions and limitations +# under the License. +# +############################################################################ + +# Build arm-uclinuxfdpiceabi binutils -- the only part of the module +# toolchain that has to be built from source. +# +# The compiling is done by the stock Arm bare-metal toolchain, which emits +# correct FDPIC objects for both C and C++. What it cannot do is *link* +# them: arm-none-eabi-ld is configured with the `armelf` emulation alone, so +# it produces an object marked "UNIX - System V" that the loader refuses. +# The FDPIC linker carries armelf_linux_fdpiceabi, and that is the whole of +# the gap. +# +# So this builds binutils and nothing else: about a minute, roughly 23 MB. +# An FDPIC GCC is not needed for any of this. +# +# Usage: build-binutils.sh <workdir> [install-prefix] +# +# Then add <install-prefix>/bin to PATH. + +set -e + +WORK="${1:?usage: build-binutils.sh <workdir> [prefix]}" +PREFIX="${2:-$WORK/toolchain}" +TARGET=arm-uclinuxfdpiceabi +BINUTILS=binutils-2.43 +J="$(getconf _NPROCESSORS_ONLN 2>/dev/null || echo 4)" + +mkdir -p "$WORK/src" "$WORK/build" + +cd "$WORK/src" +[ -d "$BINUTILS" ] || { + curl -fL -O "https://ftp.gnu.org/gnu/binutils/$BINUTILS.tar.xz"; + tar xf "$BINUTILS.tar.xz" +} + +rm -rf "$WORK/build/binutils" +mkdir -p "$WORK/build/binutils" +cd "$WORK/build/binutils" + +# --with-system-zlib because the bundled copy does not compile against the +# macOS SDK headers. Harmless elsewhere. + +"$WORK/src/$BINUTILS/configure" \ Review Comment: the script is simple, why not doc the process in documentation instead ########## tools/fdpic/init-array.ld: ########## @@ -0,0 +1,49 @@ +/**************************************************************************** + * tools/fdpic/init-array.ld + * + * SPDX-License-Identifier: Apache-2.0 + * + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. The + * ASF licenses this file to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance with the + * License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT + * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the + * License for the specific language governing permissions and limitations + * under the License. + * + ****************************************************************************/ + +/* Bounds for crt0.c to walk. + * + * The linker's built-in script defines __init_array_start and + * __init_array_end when it links an executable and not when it links a + * shared object, because a shared object is expected to be constructed by + * whoever loaded it, from DT_INIT_ARRAY. A NuttX module is loaded that way + * only through dlopen(); one that exec() runs enters its own crt0 and has to + * find the array itself. Reading DT_INIT_ARRAY out of _DYNAMIC is not an + * answer, because the addresses there are link-time ones and an FDPIC object + * cannot translate them: its two segments move independently and only the + * loader knows by how much. + * + * INSERT keeps the built-in script and adds to it, so this file replaces + * nothing. + */ + +SECTIONS +{ + .init_array : Review Comment: why not modify the standard elf ld directly? ########## tools/fdpic/nuttx-fdpic.mk: ########## @@ -0,0 +1,219 @@ +############################################################################ +# tools/fdpic/nuttx-fdpic.mk +# +# SPDX-License-Identifier: Apache-2.0 +# +# Licensed to the Apache Software Foundation (ASF) under one or more +# contributor license agreements. See the NOTICE file distributed with +# this work for additional information regarding copyright ownership. The +# ASF licenses this file to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance with the +# License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT +# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the +# License for the specific language governing permissions and limitations +# under the License. +# +############################################################################ + +# nuttx-fdpic.mk -- build out-of-tree FDPIC modules for NuttX +# +# A module is an ELF shared object whose read-only segment the target maps +# straight out of flash and executes in place, and whose writable segment is +# copied to RAM once per running instance. It links against nothing: libc +# and everything else are imported from the firmware's exported symbol table +# at load time. +# +# Usage -- a whole module is this: +# +# MODULE = hello +# SRCS = hello.c +# include /path/to/nuttx/tools/fdpic/nuttx-fdpic.mk +# +# C++ sources go in CXXSRCS instead of SRCS. +# +# Two toolchains are involved, and the split is the whole trick: +# +# * the stock Arm bare-metal compiler does the compiling. It emits +# perfectly good FDPIC objects for both C and C++. +# * arm-uclinuxfdpiceabi *binutils* does the linking, because +# arm-none-eabi-ld is built with only the `armelf` emulation and cannot +# produce an FDPIC object at all -- it silently marks the output +# "UNIX - System V" and the loader refuses it. +# +# So the from-source dependency is binutils alone, which takes about a +# minute to build. No FDPIC GCC is needed. See build-binutils.sh beside +# this file, and Documentation/components/tools/fdpic.rst. +# +# Required: +# NUTTX_DIR a configured, built NuttX tree (headers + export list) +# +# Optional: +# ARM_TOOLCHAIN prefix of the bare-metal compiler; default arm-none-eabi +# FDPIC_TOOLCHAIN prefix of the FDPIC binutils; default +# arm-uclinuxfdpiceabi +# CPU default cortex-m33 +# ENTRY entry symbol; default _start, use 0 for a library +# OPT default -Os +# LIBS shared libraries to link against +# BINDNOW '-z now' by default; set empty to leave imported +# descriptors in the lazy binding table (DT_JMPREL) +# EXTRA_CFLAGS EXTRA_CXXFLAGS EXTRA_LDFLAGS +# +# EXTRA_LDFLAGS is passed straight to ld, not through a compiler driver, so +# it takes bare linker flags: `-soname libfoo.so`, not `-Wl,-soname,libfoo.so`. + +MODULE ?= module +SRCS ?= +CXXSRCS ?= +CPU ?= cortex-m33 +ENTRY ?= _start +OPT ?= -Os + +ARM_TOOLCHAIN ?= arm-none-eabi +FDPIC_TOOLCHAIN ?= arm-uclinuxfdpiceabi + +FDPIC_DIR := $(patsubst %/,%,$(dir $(abspath $(lastword $(MAKEFILE_LIST))))) + +ifeq ($(NUTTX_DIR),) + $(error Set NUTTX_DIR to a configured, built NuttX tree) +endif + +# make has built-in defaults for CC and CXX, so ?= never fires for them and +# the host compiler silently gets the job. Test the origin instead. + +ifeq ($(origin CC),default) + CC := $(ARM_TOOLCHAIN)-gcc +endif + +ifeq ($(origin CXX),default) + CXX := $(ARM_TOOLCHAIN)-g++ +endif + +LD := $(FDPIC_TOOLCHAIN)-ld +READELF := $(FDPIC_TOOLCHAIN)-readelf + +# Common compile flags. +# +# -mfdpic is stated rather than assumed, so a mis-set toolchain fails loudly +# instead of quietly producing a plain ELF the loader will refuse. +# +# -fPIC is not optional and not implied. -mfdpic alone does not turn on PIC +# under the bare-metal compiler, and without it the link emits TEXTREL -- +# text relocations -- which cannot work when the text is executed in place +# out of read-only flash. +# +# -fno-builtin keeps GCC from open-coding calls into libc routines the +# module is supposed to import from the firmware. +# +# __STDC_NO_ATOMICS__ steers NuttX's <nuttx/atomic.h> away from the branch +# that includes <stdatomic.h> and then redefines its macros. The effect is +# that a module using C11 atomics gets NuttX's implementation -- the same one +# the firmware uses -- rather than the compiler's. + +MODCOMMON = -mcpu=$(CPU) -mthumb -mfdpic -fPIC $(OPT) \ + -fno-builtin -Wall -Wa,--noexecstack \ + -D__STDC_NO_ATOMICS__ -D__NuttX__ + +MODCFLAGS = $(MODCOMMON) -I$(NUTTX_DIR)/include $(EXTRA_CFLAGS) + +# C++ adds three flags, none of them optional. +# +# -fno-use-cxa-atexit, because the default registers each static object's +# destructor with __cxa_atexit(dtor, obj, &__dso_handle), and __dso_handle +# comes from crtbegin, which a module does not link. The link fails +# outright with "hidden symbol `__dso_handle' isn't defined". Turning it off +# also puts the destructors in .fini_array, which is what the loader walks on +# unload -- so the flag that makes the link work is also the flag that makes +# destructors run. +# +# -fno-exceptions -fno-rtti, because both need libsupc++, which a module +# linking against nothing cannot reach. + +MODCXXFLAGS = $(MODCOMMON) \ + -fno-exceptions -fno-rtti -fno-use-cxa-atexit \ + -I$(NUTTX_DIR)/include/cxx -I$(NUTTX_DIR)/include \ + $(EXTRA_CXXFLAGS) + +# Link flags, passed straight to ld. +# +# -shared is load bearing and easy to get wrong. It is what preserves +# R_ARM_FUNCDESC_VALUE relocations for imported symbols. Linking as a PIE +# with --unresolved-symbols=ignore-all also appears to work, but silently +# degrades every import to R_ARM_NONE, and the module then branches to zero +# on its first call out. +# +# The emulation has to be named because this ld supports four. +# +# -z now keeps imported function descriptors in DT_REL rather than the lazy +# binding table DT_JMPREL. The loader binds both, so this is a default rather +# than a requirement: it keeps built modules on the layout that has had the +# most hardware exposure, and leaves the lazymod fixture, which empties +# BINDNOW, a distinct case rather than what everything does. + +BINDNOW ?= -z now + +MODLDFLAGS = -m armelf_linux_fdpiceabi -shared $(BINDNOW) -e $(ENTRY) \ + -T $(FDPIC_DIR)/init-array.ld $(EXTRA_LDFLAGS) + +# crt0 is the module's own start-up file: it walks .init_array on the task +# that runs the module and then calls main, so a constructor sees that task +# rather than the one that called the loader. It is what makes ENTRY +# _start rather than main. A library is not entered, so ENTRY = 0 leaves it +# out; it gets its constructors from dlopen() instead. +# +# init-array.ld goes with it. The linker defines the bounds of .init_array +# only when it links an executable, so a shared object has to ask for them. +# It uses INSERT, so the built-in script still applies. + +ifeq ($(ENTRY),0) + CRT0OBJ = +else + CRT0OBJ = crt0.o +endif + +OBJS := $(SRCS:.c=.o) $(CXXSRCS:.cpp=.o) +TARGET := $(MODULE).fdpic +EXPORTS := .nuttx-exports + +.PHONY: all clean verify exports + +all: verify + +$(EXPORTS): $(NUTTX_DIR)/libs/libc/exec_symtab.c Review Comment: why not use https://github.com/apache/nuttx-apps/blob/master/tools/mksymtab.sh directly? please integrate your build script into the current elf build infrastructure instead creating a new one. ########## Documentation/components/tools/fdpic.rst: ########## @@ -0,0 +1,111 @@ +===================================== +fdpic: FDPIC module build tooling +===================================== + +``tools/fdpic`` is everything needed to build an FDPIC module out of tree. A +module is an ELF shared object whose read-only segment the target maps straight +out of flash and executes in place, while its writable segment is copied to RAM +once per running instance. It links against nothing: libc and everything else +are imported from the firmware's exported symbol table at load time. + +These are host tools only. ``apps/examples/fdpicxip`` uses them to rebuild its +committed module blobs, which is what they are in the tree for. The loader that +runs such a module is proposed separately; until it is in, a module built here +has nothing in NuttX to load it. + +Contents +======== + +============================ ================================================== +File Purpose +============================ ================================================== +``nuttx-fdpic.mk`` The module build itself; include it from a + two-line makefile +``fdpic-verify.sh`` Checks a built module's imports resolve against + the firmware +``nuttx-exports.sh`` Turns ``libs/libc/exec_symtab.c`` into a symbol + list +``fdpic-embed.py`` Turns a built module into a C header, for carrying + one inside an image +``build-binutils.sh`` Builds the ``arm-uclinuxfdpiceabi`` binutils, the + one from-source dependency +``crt0.c`` The module start-up file, linked into every + module that is entered +``init-array.ld`` Names the bounds of ``.init_array`` for it +============================ ================================================== + +Building a module +================= + +A whole module is three lines of makefile beside the source. Taking +``apps/examples/fdpicxip/modules/qsorter.c``, which is a module in its own +right, as the source: + +.. code:: makefile + + MODULE = qsorter + SRCS = qsorter.c + + include /path/to/nuttx/tools/fdpic/nuttx-fdpic.mk + +Then: + +.. code:: console + + $ make NUTTX_DIR=/path/to/nuttx Review Comment: the build should integrate nuttx build system instead ########## Documentation/components/tools/fdpic.rst: ########## @@ -0,0 +1,111 @@ +===================================== +fdpic: FDPIC module build tooling +===================================== + +``tools/fdpic`` is everything needed to build an FDPIC module out of tree. A +module is an ELF shared object whose read-only segment the target maps straight +out of flash and executes in place, while its writable segment is copied to RAM +once per running instance. It links against nothing: libc and everything else +are imported from the firmware's exported symbol table at load time. + +These are host tools only. ``apps/examples/fdpicxip`` uses them to rebuild its +committed module blobs, which is what they are in the tree for. The loader that +runs such a module is proposed separately; until it is in, a module built here +has nothing in NuttX to load it. + +Contents +======== + +============================ ================================================== +File Purpose +============================ ================================================== +``nuttx-fdpic.mk`` The module build itself; include it from a + two-line makefile +``fdpic-verify.sh`` Checks a built module's imports resolve against + the firmware +``nuttx-exports.sh`` Turns ``libs/libc/exec_symtab.c`` into a symbol + list +``fdpic-embed.py`` Turns a built module into a C header, for carrying + one inside an image +``build-binutils.sh`` Builds the ``arm-uclinuxfdpiceabi`` binutils, the + one from-source dependency +``crt0.c`` The module start-up file, linked into every + module that is entered +``init-array.ld`` Names the bounds of ``.init_array`` for it +============================ ================================================== + +Building a module +================= + +A whole module is three lines of makefile beside the source. Taking +``apps/examples/fdpicxip/modules/qsorter.c``, which is a module in its own +right, as the source: + +.. code:: makefile + + MODULE = qsorter + SRCS = qsorter.c + + include /path/to/nuttx/tools/fdpic/nuttx-fdpic.mk + +Then: + +.. code:: console + + $ make NUTTX_DIR=/path/to/nuttx + CC crt0.c + CC qsorter.c + LD qsorter.fdpic + OK qsorter.fdpic: FDPIC, entry 0x2a1, 4 imports resolved Review Comment: why add fdpic suffix? ########## tools/fdpic/crt0.c: ########## @@ -0,0 +1,126 @@ +/**************************************************************************** + * tools/fdpic/crt0.c + * + * SPDX-License-Identifier: Apache-2.0 + * + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. The + * ASF licenses this file to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance with the + * License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT + * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the + * License for the specific language governing permissions and limitations + * under the License. + * + ****************************************************************************/ + +/* The start-up file of an FDPIC module, the counterpart of + * arch/<arch>/src/common/crt0.c for a module that the in-tree build + * produces. A module that exec() runs is entered here rather than at main, + * so that its constructors run on the task that runs the module, in that + * task's group and with that task's data base, rather than on whichever + * task happened to call the loader. + * + * Destructors are not registered here. -fno-use-cxa-atexit puts them in + * .fini_array, which the loader walks in libelf_uninit() when the module is + * unloaded, and registering them again would run each one twice. + * + * A shared library is not entered at all, so it does not link this file. + * Its constructors run from libelf_insert() when dlopen() maps it. + */ + +/**************************************************************************** + * Included Files + ****************************************************************************/ + +#include <stdint.h> + +/**************************************************************************** + * Public Function Prototypes + ****************************************************************************/ + +int main(int argc, char *argv[]); +void exit(int status); + +/**************************************************************************** + * Private Data + ****************************************************************************/ + +/* init-array.ld defines these around .init_array. The linker's built-in + * script does not, when it links a shared object. + * + * They are declared hidden so that the compiler reaches them through the + * GOT of this object rather than through a dynamic symbol, which is what + * lets the loader resolve them with an ordinary R_ARM_RELATIVE. + * + * Each entry is a code address rather than a function descriptor: the + * linker resolves .init_array with R_ARM_RELATIVE too, not with + * R_ARM_FUNCDESC_VALUE. + */ + +extern uintptr_t __init_array_start[] __attribute__((visibility("hidden"))); +extern uintptr_t __init_array_end[] __attribute__((visibility("hidden"))); + +/**************************************************************************** + * Private Functions + ****************************************************************************/ + +/**************************************************************************** + * Name: call_initializer + * + * Description: + * Enter one .init_array entry. A plain call through a function pointer + * cannot be used: under -mfdpic the compiler would take the entry for a + * function descriptor and load a data base out of the code address. The + * data base is right already, because this runs inside the module. + * + ****************************************************************************/ + +static void call_initializer(uintptr_t entry) +{ + __asm__ __volatile__ + ( + "blx %[entry]\n" + : + : [entry] "r" (entry) + : "r0", "r1", "r2", "r3", "r12", "lr", "cc", "memory" + ); +} + +/**************************************************************************** + * Public Functions + ****************************************************************************/ + +/**************************************************************************** + * Name: _start + * + * Description: + * The entry point of a module. Runs the constructors, calls main and + * passes its return value to exit(). + * + * Input Parameters: + * argc - The number of parameters being passed. + * argv - The parameters being passed. + * + * Returned Value: + * Does not return. + * + ****************************************************************************/ + +void _start(int argc, char *argv[]) Review Comment: why not use arch/xxx/crt0.c directly ########## tools/fdpic/fdpic-embed.py: ########## @@ -0,0 +1,115 @@ +#!/usr/bin/env python3 +############################################################################ +# tools/fdpic/fdpic-embed Review Comment: why not use xxd directly ########## tools/fdpic/build-binutils.sh: ########## @@ -0,0 +1,84 @@ +#!/bin/bash +############################################################################ +# tools/fdpic/build-binutils.sh +# +# SPDX-License-Identifier: Apache-2.0 +# +# Licensed to the Apache Software Foundation (ASF) under one or more +# contributor license agreements. See the NOTICE file distributed with +# this work for additional information regarding copyright ownership. The +# ASF licenses this file to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance with the +# License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT +# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the +# License for the specific language governing permissions and limitations +# under the License. +# +############################################################################ + +# Build arm-uclinuxfdpiceabi binutils -- the only part of the module +# toolchain that has to be built from source. +# +# The compiling is done by the stock Arm bare-metal toolchain, which emits +# correct FDPIC objects for both C and C++. What it cannot do is *link* +# them: arm-none-eabi-ld is configured with the `armelf` emulation alone, so +# it produces an object marked "UNIX - System V" that the loader refuses. Review Comment: only the marker different? ########## tools/fdpic/nuttx-fdpic.mk: ########## @@ -0,0 +1,219 @@ +############################################################################ +# tools/fdpic/nuttx-fdpic.mk Review Comment: where the cmake support? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
