From afe5d0403dd791d1e66d49a5323eb24c51f383e7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Beno=C3=AEt=20Th=C3=A9baudeau?= Date: Mon, 1 Jun 2015 23:27:23 +0200 Subject: [PATCH] cc2538: Build without the Contiki target library MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The GNU linker ld searches and processes libraries and object files in the order they are specified. Library files are archive files whose members are object files. The linker handles an archive file by scanning through it for members that define symbols that have so far been referenced but not defined. But an ordinary object file is linked in the usual fashion. The C library is implicitly linked after all object files and libraries specified on the command line. Because of that, if the C library depends on the Contiki target library, e.g. for the implementation of system calls, then these dependencies are not linked, which results in undefined references. Actually, the Contiki target library also needs the C library, hence a circular dependency between these libraries, which means that explicitly adding -lc anywhere on the command line can not help. The only solution in that case is to pass these libraries to ld between --start-group and --end-group. Archives grouped in this way are searched repeatedly by the linker until no new undefined references are created. This archive grouping option has a significant performance cost for the linking stage. Moreover, having to use it and to pass -lc explicitly on the command line is unusual, which is disturbing and more complicated for users needing the C library to depend on the Contiki target library. The same would be true for circular dependencies between the Contiki target library and any other library. Another issue with the Contiki target library is that it may alter the apparent behavior of the weak vs. strong symbols, because of the way ld handles archives, which may make it discard archive object files containing strong versions of referenced symbols: - If a symbol has a weak and a strong version in this library, both inside the same object file, then the linker uses the strong definition. - If a weak symbol in this library has a strong counterpart in an object file outside, then the linker uses the strong definition. - If a strong symbol in this library is inside an object file containing other referenced symbols, and has a weak counterpart anywhere, then the linker uses the strong definition. - If a strong symbol in this library is the only symbol referenced in its object file, and has a weak counterpart in an object file outside, then the linker uses the strong definition if this library is linked first, and the weak one otherwise. - If a strong symbol in this library is the only symbol referenced in its object file, and has a weak counterpart in another object file in this library, then the linker uses the definition from the first of these objects added when creating this archive. - If a symbol has a weak and a strong version, one in this library, and the other in another library, then the rules are the same as if both were in the Contiki target library. The existence of cases where the linker uses a weak symbol despite the presence of its strong counterpart in the sources compiled then passed to the linker is very error-prone, all the more this behavior depends on the order the object and archive files are passed on the command lines, which may just result from the order of source files in lists where it apparently does not matter. Such cases would be needed in the future, e.g. to define weak default implementations of some system calls that can be overridden by platform-specific implementations, both ending up in the Contiki target library. There was already such a case used to define the UART and USB ISRs as weak aliases of default_handler(), relying on this implicit unusual behavior to keep default_handler() if the UART or USB driver was unused, which was dangerous. Since the Contiki target library was only used as an intermediate file during the build, the current commit fixes these issues by simply directly using the object files instead of building an intermediate archive from them. The CONTIKI_OBJECTFILES make variable would be incomplete if it were used as a simple prerequisite in the %.elf rule in Makefile.cc2538, because other object files are added to it after this rule. That's why .SECONDEXPANSION is used to defer its expansion. Another solution would have been to split Makefile.cc2538, with the variable assignments kept in it, and the rule definitions moved to Makefile.customrules-cc2538, but this would have required to add Makefile.customrules- files to all CC2538 platforms, only to include Makefile.customrules-cc2538. The solution used here is much simpler. Because the UART and USB ISRs were weak aliases of default_handler(), this change would imply that these ISRs would always be used by the linker instead of default_handler(), even if their drivers were configured as unused with UART_CONF_ENABLE and USB_SERIAL_CONF_ENABLE, which would be wrong. This commit fixes this issue by removing these weak aliases and putting either these ISRs or default_handler() in the vector table, depending on the configuration. Weak aliases are elegant, but Contiki's build system does not currently allow to automatically build or not source files depending on the configuration, so keeping these weak aliases would have required to add #if constructs somewhere in the source code, which would have broken their elegance and made them pointless. Signed-off-by: Benoît Thébaudeau --- cpu/cc2538/Makefile.cc2538 | 4 +++- cpu/cc2538/startup-gcc.c | 21 ++++++++++++++++----- 2 files changed, 19 insertions(+), 6 deletions(-) diff --git a/cpu/cc2538/Makefile.cc2538 b/cpu/cc2538/Makefile.cc2538 index 29795111c..56ce4a2c9 100644 --- a/cpu/cc2538/Makefile.cc2538 +++ b/cpu/cc2538/Makefile.cc2538 @@ -70,6 +70,8 @@ CPU_STARTFILES = ${addprefix $(OBJECTDIR)/,${call oname, $(CPU_START_SOURCEFILES CONTIKI_SOURCEFILES += $(CONTIKI_CPU_SOURCEFILES) $(DEBUG_IO_SOURCEFILES) CONTIKI_SOURCEFILES += $(USB_CORE_SOURCEFILES) $(USB_ARCH_SOURCEFILES) +.SECONDEXPANSION: + ### Don't treat the .elf as intermediate .PRECIOUS: %.elf %.hex %.bin @@ -83,7 +85,7 @@ $(OBJECTDIR)/ieee-addr.o: ieee-addr.c FORCE | $(OBJECTDIR) ### Compilation rules CUSTOM_RULE_LINK=1 -%.elf: $(CPU_STARTFILES) %.co $(PROJECT_OBJECTFILES) $(PROJECT_LIBRARIES) contiki-$(TARGET).a $(LDSCRIPT) +%.elf: $(CPU_STARTFILES) $$(CONTIKI_OBJECTFILES) %.co $(PROJECT_OBJECTFILES) $(PROJECT_LIBRARIES) $(LDSCRIPT) $(TRACE_LD) $(Q)$(LD) $(LDFLAGS) ${filter-out $(LDSCRIPT) %.a,$^} ${filter %.a,$^} $(TARGET_LIBFILES) -o $@ diff --git a/cpu/cc2538/startup-gcc.c b/cpu/cc2538/startup-gcc.c index 2aa82894e..944c6a6e9 100644 --- a/cpu/cc2538/startup-gcc.c +++ b/cpu/cc2538/startup-gcc.c @@ -46,8 +46,6 @@ /*---------------------------------------------------------------------------*/ extern int main(void); /*---------------------------------------------------------------------------*/ -#define WEAK_ALIAS(x) __attribute__ ((weak, alias(#x))) -/*---------------------------------------------------------------------------*/ /* System handlers provided here */ void reset_handler(void); void nmi_handler(void); @@ -64,11 +62,24 @@ void cc2538_rf_rx_tx_isr(void); void cc2538_rf_err_isr(void); void udma_isr(void); void udma_err_isr(void); -void usb_isr(void) WEAK_ALIAS(default_handler); -void uart0_isr(void) WEAK_ALIAS(default_handler); -void uart1_isr(void) WEAK_ALIAS(default_handler); void crypto_isr(void); +/* Link in the USB ISR only if USB is enabled */ +#if USB_SERIAL_CONF_ENABLE +void usb_isr(void); +#else +#define usb_isr default_handler +#endif + +/* Likewise for the UART[01] ISRs */ +#if UART_CONF_ENABLE +void uart0_isr(void); +void uart1_isr(void); +#else /* UART_CONF_ENABLE */ +#define uart0_isr default_handler +#define uart1_isr default_handler +#endif /* UART_CONF_ENABLE */ + /* Boot Loader Backdoor selection */ #if FLASH_CCA_CONF_BOOTLDR_BACKDOOR /* Backdoor enabled */