You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Pavel Pisa <pp...@pikron.com> on 2021/07/17 23:10:03 UTC
NuttX ELF loadable applications and modules build broken probably for the most targets.
Hello everybody,
CONFIG_EXAMPLES_MODULE and or CONFIG_EXAMPLES_ELF is enabled then
build fails (i.e. for tools/configure.sh lx_cpu:nsh) on my system.
I use Debian provided arm-none-eabi-gcc by default. The error reported:
-----------------------------------------------------------------------------------
make[5]: Entering
directory '/home/pi/repo/nuttx/src/apps/examples/module/drivers/chardev'
MODULECC: chardev.c
arm-none-eabi-gcc -c -fno-builtin -Wall -Wstrict-prototypes -Wshadow -Wundef -Os -fno-strict-aliasing -fno-strength-reduce -fomit-frame-pointer -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -isystem "/home/pi/repo/nuttx/src/nuttx/include" -D__NuttX__ -pipe -I "/home/pi/repo/nuttx/src/apps/include" -mlong-calls -D__KERNEL__
chardev.c -o chardev.o
MODULELD: chardev.o
arm-none-eabi-gcc -r -e
module_initialize -T /home/pi/repo/nuttx/src/nuttx/libs/libc/modlib/gnu-elf.ld -o
chardev chardev.o
/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: error:
chardev.o uses VFP register arguments, chardev does not
/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: failed to
merge target specific data of file chardev.o
collect2: error: ld returned 1 exit status
-----------------------------------------------------------------------------------
The cause is that LD has been changed to point to arm-none-eabi-gcc .
Use of GCC wrapper for the final image linking can probably help
with correct C++ libraries selection, possible link time optimizations
etc... But redefinition of LD symbol causes troubles when only
partial linking is required because GCC includes default libraries
even when -r relocatable output is required. Other problem is that
when GCC locates librares or even rebuilds machine code then same
set of arch flags should be specified, else mismatch of incompatible
codes is reported.
I have solved problem for LX_CPU by next change of flags used
for ELF loadable applications and modules
-----------------------------------------------------------------------------------
diff --git a/boards/arm/lpc17xx_40xx/lx_cpu/scripts/Make.defs b/boards/arm/lpc17xx_40xx/lx_cpu/scripts/Make.defs
index de893534d8..fca2650e38 100644
--- a/boards/arm/lpc17xx_40xx/lx_cpu/scripts/Make.defs
+++ b/boards/arm/lpc17xx_40xx/lx_cpu/scripts/Make.defs
@@ -72,7 +72,7 @@ LDNXFLATFLAGS = -e main -s 2048
CELFFLAGS = $(CFLAGS) -mlong-calls # --target1-abs
CXXELFFLAGS = $(CXXFLAGS) -mlong-calls # --target1-abs
-LDELFFLAGS = -r -e main
+LDELFFLAGS = $(CELFFLAGS) -nostartfiles -nodefaultlibs -r -e main
ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
LDELFFLAGS += -T "${shell cygpath -w $(BOARD_DIR)$(DELIM)scripts$(DELIM)gnu-elf.ld}"
else
@@ -83,7 +83,7 @@ endif
CMODULEFLAGS = $(CFLAGS) -mlong-calls # --target1-abs
-LDMODULEFLAGS = -r -e module_initialize
+LDMODULEFLAGS = $(CMODULEFLAGS) -nostartfiles -nodefaultlibs -r -e module_initialize
ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
LDMODULEFLAGS += -T "${shell cygpath -w $(TOPDIR)/libs/libc/modlib/gnu-elf.ld}"
else
-----------------------------------------------------------------------------------
I expect that same adjustment is required for many other targets.
I can prepare patch for our board only or for all where I find
same LDMODULEFLAGS and LDELFFLAGS pattern.
Other option is to return back to plain LD and define LINK or other
symbol for linker which would point to GCC wrapper. But such change
would require probably changes in the APPS and user projects
using NuttX with own APPS or with export support.
I have not updated my OMK builds to link separately compiled applications
with NuttX exported link kit with GCC wrapper. If the libraries
are collected by export, is it still necessary to use GCC wrapper?
Or was LTO, whole program optimization, automatic C++ templates
instances generaton reason to switch to linking through GCC?
Best wishes,
Pavel
Pavel Pisa
==================================================
PiKRON s.r.o. Phone/Fax: +420 284684676
Kankovskeho 1235 Phone: +420 234697622
182 00 Praha 8 WWW: http://www.pikron.com/
Czech Republic e-mail: pikron@pikron.com
==================================================
Re: NuttX export cannot set some variables (i.e. LDSTARTGROUP LDENDGROUP HEAD_OBJ)
Posted by Pavel Pisa <pp...@pikron.com>.
Hello Alan,
On Sunday 17 of April 2022 14:22:21 Alan Carvalho de Assis wrote:
> Did you have some idea about last time that "make export" was working?
>
> This feature is used by PX4 project too. I think it needs to be fixed
> before current release. I'm on vacation without a laptop to test it.
I think that some toolchain options did never propagate to
nuttx-export/scripts/Make.defs
but that was not a problem till the linking started to alter between
GCC and GNU LD which started to need LDSTARTGROUP and LDENDGROUP
to adjust these once to use and once not -Wl,
I have somehow adapted for this missing information in my code
ifneq ($(filter -Wl%, $(NXFLATLDFLAGS1)$(NXFLATLDFLAGS2)),)
GCC_LD_OPTION = -Wl,
endif
But with extension of support of the pysimCoder, Matlab Simulink NuttX target
and our OMK based motion, CAN and RS-485 communication project to RISC-V based
ESP32C3 the missing/empty HEAD_OBJ information is already hard to resolve
automatically problem. So I rise priority of the problem reported on July 2021
on mailinglist only because if not solved we need to do manual adjustment each
time when export is copied into our projects.
My finding and thoughts are summarized at
https://github.com/apache/incubator-nuttx/issues/6082
Best wishes,
Pavel
Re: NuttX export cannot set some variables (i.e. LDSTARTGROUP LDENDGROUP HEAD_OBJ)
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
Hi Pavel,
Did you have some idea about last time that "make export" was working?
This feature is used by PX4 project too. I think it needs to be fixed
before current release. I'm on vacation without a laptop to test it.
About CMake support is was done by Matias some years ago, but it suffered
resistance to enter because NuttX current building system is working fine
for many years. So discussing about transition and how to get both working
without duplicating users work is a question to answer.
BR,
Alan
On Saturday, April 16, 2022, Pavel Pisa <pp...@pikron.com> wrote:
> Hello everybody,
>
> as it seems that new release is near to be published
> I would like to remind that here is significant
> issue which complicates use of NuttX export to base more
> applications on it, i.e. pysimCoder https://github.com/
> robertobucher/pysimCoder
> our OMK build which allows to build complete CAN/CANopen
> OrtCAN infrastructure http://ortcan.sourceforge.net/
> and uLAN RS-485 communication http://ulan.sourceforge.net/,
> motion control PXMC http://pxmc.org/ etc.
>
> The code has been successfully tested with NuttX in the past
> and we want to test our CAN/CANopen framework with actual
> NuttX even on ESP32C3 now when Jan Charvat's CAN (TWAI)
> driver has been included.
>
> I can help to solve the problem but some feedback is necessary.
> It seems that actual release will be based on GNU make system.
> Is that right? What are plans with cmake?
> If it worth to dive into actual stuff.
>
> Are there some suggestions and expectations what would
> broke if right arch Makefile with low level defines
> is included into tools/Makefile.export
>
> arch/{avr,hc,mips,misoc,or1k,renesas,risc-v,sim,x86,x86_64,
> xtensa}/src/Makefile
>
> How should it be included to work for all architectures?
>
> The issue is open not keep remembering this significant
> issue with use of NuttX as base for more complex projects
> which cannot be directly hacked into NuttX apps repo
>
> https://github.com/apache/incubator-nuttx/issues/6082
>
> Best wishes,
>
> Pavel
>
> --
> Pavel Pisa
> phone: +420 603531357
> e-mail: pisa@cmp.felk.cvut.cz
> Department of Control Engineering FEE CVUT
> Karlovo namesti 13, 121 35, Prague 2
> university: http://control.fel.cvut.cz/
> company: https://www.pikron.com/
> personal: http://cmp.felk.cvut.cz/~pisa
> projects: https://www.openhub.net/accounts/ppisa
> CAN related:http://canbus.pages.fel.cvut.cz/
> Open Technologies Research Education and Exchange Services
> https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
>
>
Re: NuttX export cannot set some variables (i.e. LDSTARTGROUP LDENDGROUP HEAD_OBJ)
Posted by Pavel Pisa <pp...@pikron.com>.
Hello everybody,
as it seems that new release is near to be published
I would like to remind that here is significant
issue which complicates use of NuttX export to base more
applications on it, i.e. pysimCoder https://github.com/robertobucher/pysimCoder
our OMK build which allows to build complete CAN/CANopen
OrtCAN infrastructure http://ortcan.sourceforge.net/
and uLAN RS-485 communication http://ulan.sourceforge.net/,
motion control PXMC http://pxmc.org/ etc.
The code has been successfully tested with NuttX in the past
and we want to test our CAN/CANopen framework with actual
NuttX even on ESP32C3 now when Jan Charvat's CAN (TWAI)
driver has been included.
I can help to solve the problem but some feedback is necessary.
It seems that actual release will be based on GNU make system.
Is that right? What are plans with cmake?
If it worth to dive into actual stuff.
Are there some suggestions and expectations what would
broke if right arch Makefile with low level defines
is included into tools/Makefile.export
arch/{avr,hc,mips,misoc,or1k,renesas,risc-v,sim,x86,x86_64,xtensa}/src/Makefile
How should it be included to work for all architectures?
The issue is open not keep remembering this significant
issue with use of NuttX as base for more complex projects
which cannot be directly hacked into NuttX apps repo
https://github.com/apache/incubator-nuttx/issues/6082
Best wishes,
Pavel
--
Pavel Pisa
phone: +420 603531357
e-mail: pisa@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
company: https://www.pikron.com/
personal: http://cmp.felk.cvut.cz/~pisa
projects: https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
Re: NuttX export cannot set some variables (i.e. LDSTARTGROUP LDENDGROUP) Was: NuttX ELF loadable applications and modules build broken
Posted by Pavel Pisa <pp...@pikron.com>.
Hello Xiang Xiao,
On Monday 19 of July 2021 16:59:01 Xiang Xiao wrote:
> > From: Pavel Pisa <pp...@pikron.com>
> > Sent: Monday, July 19, 2021 10:46 PM
...
> > # NuttX modules are ELF binaries.
> > # Non-ELF platforms like macOS need to use a separate ELF toolchain.
> > ifeq ($(CONFIG_HOST_MACOS),y)
> > # eg. brew install x86_64-elf-gcc
> > MODULECC = x86_64-elf-gcc
> > MODULELD = x86_64-elf-ld
>
> How about we change to x86_64-elf-gcc too?
It would lead to unification which I like.
It would be great is somebody working on MAC OS
can try such change and do real tests.
I have found cause for broken/empty
LDENDGROUP and LDSTARTGROUP in exported Make.defs
nuttx-export-10.1.0-RC1/scripts/Make.defs
as
LDENDGROUP =
LDFLAGS = -nostartfiles -nodefaultlibs
LDSTARTGROUP =
The reason is that
tools/mkexport.sh
invokes
${MAKE} -C "${TOPDIR}/tools" -f Makefile.export TOPDIR="${TOPDIR}"
tools/Makefile.export includes
include $(TOPDIR)/.config
include $(EXPORTDIR)/Make.defs
and generates temporary ${EXPORTDIR}/makeinfo.sh"
But LDENDGROUP and LDSTARTGROUP are defined in
arch/{avr,hc,mips,misoc,or1k,renesas,risc-v,sim,x86,x86_64,xtensa}/src/Makefile
which are not sourced by tools/Makefile.export.
Only exception is arch/arm/src/rtl8720c/Toolchain.defs which could
probably work.
The question is if to try to source complete Makefile by export
(probably would lead to other problems) or to change how architectures
defines these options for toolchain.
It can take more time to solve this problem clean way.
May it be it solves if build system is switched.
I would prefer meson + ninja above cmake or stay with
GNU make, but cmake support is one of the most robust
options today.
As for temporal workaround I suggest to define some flag
in each Make.defs setting LD=*-gcc to indicate that
LINK_IS_DONE_BY_CC=y
Or may it be set it in arch Kconfig then it can be used
even during configuration or can be configurable,
which would do probably more harm than proffit.
Actual state is that LDENDGROUP and LDSTARTGROUP
mustnot be used in builds using exported Make.defs
directly. Use requires check that they are empty
and workaround as has been hacked into pysimCoder.
Best wishes,
Pavel
RE: NuttX ELF loadable applications and modules build broken probably for the most targets.
Posted by Xiang Xiao <xi...@gmail.com>.
> -----Original Message-----
> From: Pavel Pisa <pp...@pikron.com>
> Sent: Monday, July 19, 2021 10:46 PM
> To: dev@nuttx.apache.org; Xiang Xiao <xi...@gmail.com>
> Cc: Gregory Nutt <sp...@gmail.com>; Michal Lenc <le...@fel.cvut.cz>; Abdelatif Guettouche
> <ab...@gmail.com>; Alan Carvalho de Assis <ac...@gmail.com>
> Subject: Re: NuttX ELF loadable applications and modules build broken probably for the most targets.
>
> Hello Xiang Xiao,
>
> Alan has approved pull
>
> https://github.com/apache/incubator-nuttx/pull/4173
>
> There is question what to do with SIM target and others in the longer term. I have removed them from the pull which has been merged.
>
> I resent text from previous email with correct identity to pass to the list this time and document isssues.
>
> On Sunday 18 of July 2021 18:39:12 Pavel Pisa wrote:
> > From the search, it seems that mips renesas risc-v x86_64 xtensa has
> > not switched to linking by GCC.... so I hope I have not break something there.
>
> For example, correction of SIM target seems to be walk in the minefield.
>
> macOS (sim-02)
> Configuration/Tool: sim/sotest
> ------------------------------------------------------------------------------------
> Cleaning...
> Configuring...
> Building NuttX...
> x86_64-elf-ld: unrecognised emulation mode: cmodel=large Supported emulations: elf_x86_64 elf_i386 elf_iamcu elf32_x86_64 elf_l1om
> elf_k1om
> make[5]: *** [sotest] Error 1
> make[5]: Target `install' not remade because of errors.
> make[4]: *** [sotest_install] Error 2
> x86_64-elf-ld: unrecognised emulation mode: cmodel=large Supported emulations: elf_x86_64 elf_i386 elf_iamcu elf32_x86_64 elf_l1om
> elf_k1om
> make[5]: *** [modprint] Error 1
> make[5]: Target `install' not remade because of errors.
> make[4]: *** [modprint_install] Error 2
> make[4]: Target `all' not remade because of errors.
> make[3]: *** [build] Error 2
> make[3]: Target `all' not remade because of errors.
> make[2]: *** [/Users/runner/work/incubator-nuttx/incubator-nuttx/sources/apps/examples/sotest_all] Error 2
> make[2]: Target `/Users/runner/work/incubator-nuttx/incubator-nuttx/sources/apps/libapps.a' not remade because of errors.
> make[1]: *** [all] Error 2
> make: *** [/Users/runner/work/incubator-nuttx/incubator-nuttx/sources/apps/libapps.a] Error 2
> make: Target `all' not remade because of errors.
> /Users/runner/work/incubator-nuttx/incubator-nuttx/sources/nuttx/tools/testbuild.sh: line
> 252: /Users/runner/work/incubator-nuttx/incubator-nuttx/sources/nuttx/../nuttx/nuttx.manifest: No such file or directory
> Normalize sim/sotest
>
> As I have checked most of the architectures does not use GCC as LD or doesnot define LDMODULEFLAGS or LDELFFLAGS.
>
> So it seems that changes to other ten ARM architectures do not have purpose for now.
>
> The sim target is special
>
> It defines GCC as LD at top
>
> CC = $(CROSSDEV)cc
> CXX = $(CROSSDEV)c++
> CPP = $(CROSSDEV)cc -E -P -x c
> LD = $(CROSSDEV)cc
>
> but then plain LD in MAC OS case
>
> # NuttX modules are ELF binaries.
> # Non-ELF platforms like macOS need to use a separate ELF toolchain.
> ifeq ($(CONFIG_HOST_MACOS),y)
> # eg. brew install x86_64-elf-gcc
> MODULECC = x86_64-elf-gcc
> MODULELD = x86_64-elf-ld
How about we change to x86_64-elf-gcc too?
> MODULESTRIP = x86_64-elf-strip --strip-unneeded endif
>
> So I can add
>
> LDMODULEFLAGS += ...
>
> in else when not on MAC OS....
>
> I have removed sim change from the pull request.
>
> Really there should be define which allows to distinguish which link slution is used and select right behavior...
>
> Best wishes,
>
> Pavel
Re: NuttX ELF loadable applications and modules build broken probably for the most targets.
Posted by Pavel Pisa <pp...@pikron.com>.
Hello Xiang Xiao,
Alan has approved pull
https://github.com/apache/incubator-nuttx/pull/4173
There is question what to do with SIM target and others
in the longer term. I have removed them from the pull
which has been merged.
I resent text from previous email with correct identity
to pass to the list this time and document isssues.
On Sunday 18 of July 2021 18:39:12 Pavel Pisa wrote:
> From the search, it seems that mips renesas risc-v x86_64 xtensa has not
> switched to linking by GCC.... so I hope I have not break something there.
For example, correction of SIM target seems to be walk in
the minefield.
macOS (sim-02)
Configuration/Tool: sim/sotest
------------------------------------------------------------------------------------
Cleaning...
Configuring...
Building NuttX...
x86_64-elf-ld: unrecognised emulation mode: cmodel=large
Supported emulations: elf_x86_64 elf_i386 elf_iamcu elf32_x86_64 elf_l1om elf_k1om
make[5]: *** [sotest] Error 1
make[5]: Target `install' not remade because of errors.
make[4]: *** [sotest_install] Error 2
x86_64-elf-ld: unrecognised emulation mode: cmodel=large
Supported emulations: elf_x86_64 elf_i386 elf_iamcu elf32_x86_64 elf_l1om elf_k1om
make[5]: *** [modprint] Error 1
make[5]: Target `install' not remade because of errors.
make[4]: *** [modprint_install] Error 2
make[4]: Target `all' not remade because of errors.
make[3]: *** [build] Error 2
make[3]: Target `all' not remade because of errors.
make[2]: *** [/Users/runner/work/incubator-nuttx/incubator-nuttx/sources/apps/examples/sotest_all] Error 2
make[2]: Target `/Users/runner/work/incubator-nuttx/incubator-nuttx/sources/apps/libapps.a' not remade because of errors.
make[1]: *** [all] Error 2
make: *** [/Users/runner/work/incubator-nuttx/incubator-nuttx/sources/apps/libapps.a] Error 2
make: Target `all' not remade because of errors.
/Users/runner/work/incubator-nuttx/incubator-nuttx/sources/nuttx/tools/testbuild.sh: line
252: /Users/runner/work/incubator-nuttx/incubator-nuttx/sources/nuttx/../nuttx/nuttx.manifest: No such file or directory
Normalize sim/sotest
As I have checked most of the architectures does not use
GCC as LD or doesnot define LDMODULEFLAGS or LDELFFLAGS.
So it seems that changes to other ten ARM architectures
do not have purpose for now.
The sim target is special
It defines GCC as LD at top
CC = $(CROSSDEV)cc
CXX = $(CROSSDEV)c++
CPP = $(CROSSDEV)cc -E -P -x c
LD = $(CROSSDEV)cc
but then plain LD in MAC OS case
# NuttX modules are ELF binaries.
# Non-ELF platforms like macOS need to use a separate ELF toolchain.
ifeq ($(CONFIG_HOST_MACOS),y)
# eg. brew install x86_64-elf-gcc
MODULECC = x86_64-elf-gcc
MODULELD = x86_64-elf-ld
MODULESTRIP = x86_64-elf-strip --strip-unneeded
endif
So I can add
LDMODULEFLAGS += ...
in else when not on MAC OS....
I have removed sim change from the pull request.
Really there should be define which allows to distinguish
which link slution is used and select right behavior...
Best wishes,
Pavel
Re: NuttX ELF loadable applications and modules build broken probably for the most targets.
Posted by Pavel Pisa <pp...@pikron.com>.
Hello Xiang Xiao,
thanks for response.
On Sunday 18 of July 2021 13:13:50 Xiang Xiao wrote:
> On Sat, Jul 17, 2021 at 4:10 PM Pavel Pisa <pp...@pikron.com> wrote:
> > Hello everybody,
> >
> > CONFIG_EXAMPLES_MODULE and or CONFIG_EXAMPLES_ELF is enabled then
> > build fails (i.e. for tools/configure.sh lx_cpu:nsh) on my system.
> > I use Debian provided arm-none-eabi-gcc by default. The error reported:
...
> Thanks for reporting this issue. I am wondering why CI can't catch this
> issue before the change merge.
It is possible that none of the targets configuration
used for CI enables
CONFIG_EXAMPLES_MODULE and or CONFIG_EXAMPLES_ELF
Or even when it enables them but architecture uses GCC default
multilib then it can pass. Problem should demonstrate itself
during linking (missing symbols required by NEWLIB libc and crt0)
but it is possible that only for arm-none-eabi-not for *-nuttx-*.
CONFIG_MODULE and or CONFIG_ELF alone allows to build end link
NuttX but problems appears later when somebody tries use feature
in own apps or own build against export.
> > I expect that same adjustment is required for many other targets.
> > I can prepare patch for our board only or for all where I find
> > same LDMODULEFLAGS and LDELFFLAGS pattern.
>
> It will be great if you can fix the problem for other boards too, thanks.
The pull request draft, it would be great if checked by other boards
maintainers as well
https://github.com/apache/incubator-nuttx/pull/4173
> > Other option is to return back to plain LD and define LINK or other
> > symbol for linker which would point to GCC wrapper. But such change
> > would require probably changes in the APPS and user projects
> > using NuttX with own APPS or with export support.
> >
> > I have not updated my OMK builds to link separately compiled applications
> > with NuttX exported link kit with GCC wrapper. If the libraries
> > are collected by export, is it still necessary to use GCC wrapper?
> > Or was LTO, whole program optimization, automatic C++ templates
> > instances generaton reason to switch to linking through GCC?
>
> Please see the discussion here:
> https://github.com/apache/incubator-nuttx/pull/3836
> https://github.com/apache/incubator-nuttx/pull/3900
OK, I understand reasons to use GCC wrapper for linking,
even for modules and ELF but I would prefer to define and
use LINK variable to refer to linker and leave LD to point
to real LD, because for some purposes, as conversion of tar
images and other stuff into object files or for sother specific
modifications of the object files it is much easier to use.
But it is my preference and not strong one...
But I would appreciate if there is deterministic
mechanisms how to check if linking through GCC is
used for given arch in exported Make.defs i.e.
GCC_USED_FOR_LINKING=y.
Our actual solution in pysimCoder is dirty hack
ifneq ($(filter -Wl%, $(NXFLATLDFLAGS1)$(NXFLATLDFLAGS2)),)
GCC_LD_OPTION = -Wl,
endif
I have hacked our OMK template to override LD for now
to point to GNU ld
https://github.com/ppisa/nuttx-devel/tree/master/nuttx-omk-template
independently to NuttX export. I would reconsider the setup
when NuttX is released or start to use LTO.
The pysimCoder have been adapted to support both linking options
by us about month ago
https://github.com/robertobucher/pysimCoder/blob/master/CodeGen/templates/nuttx.tmf
To support more smooth switch, I would be happy if
LDSTARTGROUP
LDENDGROUP
are added correctly to exported Make.defs. But my actual
nuttx-export-10.1.0-RC1/scripts/Make.defs
shows
LDENDGROUP =
LDFLAGS = -nostartfiles -nodefaultlibs
LDSTARTGROUP =
I can try to investigate reason for empty values but export has been
added by Abdelatif Guettouche so he can find problem faster or can have
some opinion where is a problem.
From the search, it seems that mips renesas risc-v x86_64 xtensa has not switched
to linking by GCC.... so I hope I have not break something there.
Best wishes,
Pavel
Re: NuttX ELF loadable applications and modules build broken probably
for the most targets.
Posted by Xiang Xiao <xi...@gmail.com>.
On Sat, Jul 17, 2021 at 4:10 PM Pavel Pisa <pp...@pikron.com> wrote:
> Hello everybody,
>
> CONFIG_EXAMPLES_MODULE and or CONFIG_EXAMPLES_ELF is enabled then
> build fails (i.e. for tools/configure.sh lx_cpu:nsh) on my system.
> I use Debian provided arm-none-eabi-gcc by default. The error reported:
>
>
> -----------------------------------------------------------------------------------
> make[5]: Entering
> directory '/home/pi/repo/nuttx/src/apps/examples/module/drivers/chardev'
> MODULECC: chardev.c
> arm-none-eabi-gcc -c -fno-builtin -Wall -Wstrict-prototypes -Wshadow
> -Wundef -Os -fno-strict-aliasing -fno-strength-reduce -fomit-frame-pointer
> -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -isystem
> "/home/pi/repo/nuttx/src/nuttx/include" -D__NuttX__ -pipe -I
> "/home/pi/repo/nuttx/src/apps/include" -mlong-calls -D__KERNEL__
> chardev.c -o chardev.o
> MODULELD: chardev.o
> arm-none-eabi-gcc -r -e
> module_initialize -T
> /home/pi/repo/nuttx/src/nuttx/libs/libc/modlib/gnu-elf.ld -o
> chardev chardev.o
> /usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: error:
> chardev.o uses VFP register arguments, chardev does not
> /usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: failed to
> merge target specific data of file chardev.o
> collect2: error: ld returned 1 exit status
>
> -----------------------------------------------------------------------------------
>
> The cause is that LD has been changed to point to arm-none-eabi-gcc .
> Use of GCC wrapper for the final image linking can probably help
> with correct C++ libraries selection, possible link time optimizations
> etc... But redefinition of LD symbol causes troubles when only
> partial linking is required because GCC includes default libraries
> even when -r relocatable output is required. Other problem is that
> when GCC locates librares or even rebuilds machine code then same
> set of arch flags should be specified, else mismatch of incompatible
> codes is reported.
>
>
Thanks for reporting this issue. I am wondering why CI can't catch this
issue before the change merge.
> I have solved problem for LX_CPU by next change of flags used
> for ELF loadable applications and modules
>
>
> -----------------------------------------------------------------------------------
> diff --git a/boards/arm/lpc17xx_40xx/lx_cpu/scripts/Make.defs
> b/boards/arm/lpc17xx_40xx/lx_cpu/scripts/Make.defs
> index de893534d8..fca2650e38 100644
> --- a/boards/arm/lpc17xx_40xx/lx_cpu/scripts/Make.defs
> +++ b/boards/arm/lpc17xx_40xx/lx_cpu/scripts/Make.defs
> @@ -72,7 +72,7 @@ LDNXFLATFLAGS = -e main -s 2048
> CELFFLAGS = $(CFLAGS) -mlong-calls # --target1-abs
> CXXELFFLAGS = $(CXXFLAGS) -mlong-calls # --target1-abs
>
> -LDELFFLAGS = -r -e main
> +LDELFFLAGS = $(CELFFLAGS) -nostartfiles -nodefaultlibs -r -e main
> ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
> LDELFFLAGS += -T "${shell cygpath -w
> $(BOARD_DIR)$(DELIM)scripts$(DELIM)gnu-elf.ld}"
> else
> @@ -83,7 +83,7 @@ endif
>
> CMODULEFLAGS = $(CFLAGS) -mlong-calls # --target1-abs
>
> -LDMODULEFLAGS = -r -e module_initialize
> +LDMODULEFLAGS = $(CMODULEFLAGS) -nostartfiles -nodefaultlibs -r -e
> module_initialize
> ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
> LDMODULEFLAGS += -T "${shell cygpath -w
> $(TOPDIR)/libs/libc/modlib/gnu-elf.ld}"
> else
>
> -----------------------------------------------------------------------------------
>
> I expect that same adjustment is required for many other targets.
> I can prepare patch for our board only or for all where I find
> same LDMODULEFLAGS and LDELFFLAGS pattern.
>
>
It will be great if you can fix the problem for other boards too, thanks.
> Other option is to return back to plain LD and define LINK or other
> symbol for linker which would point to GCC wrapper. But such change
> would require probably changes in the APPS and user projects
> using NuttX with own APPS or with export support.
>
> I have not updated my OMK builds to link separately compiled applications
> with NuttX exported link kit with GCC wrapper. If the libraries
> are collected by export, is it still necessary to use GCC wrapper?
> Or was LTO, whole program optimization, automatic C++ templates
> instances generaton reason to switch to linking through GCC?
>
>
Please see the discussion here:
https://github.com/apache/incubator-nuttx/pull/3836
https://github.com/apache/incubator-nuttx/pull/3900
> Best wishes,
>
> Pavel
>
> Pavel Pisa
>
> ==================================================
> PiKRON s.r.o. Phone/Fax: +420 284684676
> Kankovskeho 1235 Phone: +420 234697622
> 182 00 Praha 8 WWW: http://www.pikron.com/
> Czech Republic e-mail: pikron@pikron.com
> ==================================================
>