The official git repository for OSD-Contiki, the open source OS for the Internet of Things
Find a file
Benoît Thébaudeau afe5d0403d cc2538: Build without the Contiki target library
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-<target> 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 <benoit.thebaudeau.dev@gmail.com>
2015-06-05 21:55:51 +02:00
apps Merge pull request #883 from cmorty/pull/global-macros 2015-05-18 21:33:00 +02:00
core Merge pull request #918 from cetic/pr-multi-dodag-support 2015-05-26 16:32:10 +02:00
cpu cc2538: Build without the Contiki target library 2015-06-05 21:55:51 +02:00
dev Disable PACKETBUF_ATTR_PACKET_TYPE in the non-Rime case by default 2015-05-06 16:36:15 +02:00
doc Do not try to build cc26xxware documentation 2015-05-17 15:01:02 +01:00
examples cc2538: aes: Add support for 192- and 256-bit keys 2015-06-02 21:41:56 +02:00
platform cc2538: aes: Add support for 192- and 256-bit keys 2015-06-02 21:41:56 +02:00
regression-tests Add regression-test for tools 2015-05-17 12:26:08 +02:00
tools fix mixture of spaces and tabs for z1-bsl-nopic 2015-06-01 17:34:18 +02:00
.gitignore Zolertia Re-Mote platform ported to Contiki, developed whitin RERUM FP7 European project (grant #609094). 2015-05-29 22:04:43 +02:00
.gitmodules Pull CC26xxware as a submodule 2015-05-17 15:01:01 +01:00
.travis.yml Merge pull request #1074 from g-oikonomou/cc26xx/contrib/new-cc26xxware 2015-05-21 10:01:00 +02:00
CONTRIBUTING.md Adding a CONTRIBUTING file to use github feature 2014-07-04 09:29:12 +02:00
LICENSE Removed the explicit year 2012 to make it more generic 2012-10-25 23:08:54 +02:00
Makefile.include Makefile.include: Remove unused MODULESSUBST 2015-06-01 22:09:58 +02:00
README-BUILDING.md Rename to md 2013-03-26 23:15:37 +01:00
README-EXAMPLES.md Several minor consistency improvements. 2013-07-31 00:55:31 +02:00
README.md Rename to md 2013-03-26 23:15:37 +01:00

The Contiki Operating System

Build Status

Contiki is an open source operating system that runs on tiny low-power microcontrollers and makes it possible to develop applications that make efficient use of the hardware while providing standardized low-power wireless communication for a range of hardware platforms.

Contiki is used in numerous commercial and non-commercial systems, such as city sound monitoring, street lights, networked electrical power meters, industrial monitoring, radiation monitoring, construction site monitoring, alarm systems, remote house monitoring, and so on.

For more information, see the Contiki website:

http://contiki-os.org