[libgloss] * configure.in: Add rl78. * configure: Regenerate. * rl78: New directory

[newlib]
* configure.host: Add rl78.
* libc/include/machine/ieeefp.h: Add rl78 support.
* libc/include/machine/setjmp.h: Add rl78 support.
* libc/machine/configure.in: Add rl78.
* libc/machine/rl78: New directory.
Initial commit
* libc/machine/rl78/setjmp.S: Convert from CPP macros to GAS macros, to avoid dependence on the line separation character.

* rl78/crt0.S (_interrupt_vector_table): Convert from CPP macros
to GAS macros, to avoid dependence on the line separation
character.
Find and use latest installed GNURL78 toolchain automatically.
Add reset action to terminal target of Makefile. If reset signal is routed to MCU and reset action is not requested, reset signal will be held low.
In GNURL78 v13.01 __far keyword is fixed. Now it is possible to use far pointers to flash area.
Added the PmodRF3 demo for Renesas RL78G14 board.
Added the PmodRF3 demo for Renesas RL78G14 board.
Added 3 more functions.
Added the TIME driver for RL78G14.
Moved #defines so that UIP_TCPIP_HLEN and UIP_LLH_LEN are defined before they are used
Make 0 the default link-layer header length, as far as uIP is concerned. Most currently used linke layers (specifically, 802.15.4) has adaptation layers that use separate buffers, so there is no need to reserve space in the uIP buffer.
Removed redundant #ifdef
Fixed a severe error in the bugfix: the conditional was reversed. The check must be if the TCP MSS is larger than the BUFSIZE and not the other way around.
Added an API for getting a callback when a ping reply is received.
cc2538: Set the type of the .nrdata output section to NOLOAD

The .nrdata section is volatile, so its initialization must be controlled by the
application, and not be automatically done by the startup code. It should
neither be zeroed like .bss, nor be initialized from data in flash memory like
.data. This was already supposed to be the case, but the output section type of
.nrdata was not set to NOLOAD, causing the generated ELF .nrdata section header
to be of type PROGBITS instead of NOBITS, i.e. load data was generated to be
programmed in RAM, thus producing huge unprogrammable .bin files.

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Merge pull request #502 from adamdunkels/push/fix-the-ipv6-bugfix

Fix the IPv6 bugfix
Correct the operator in the comment so that it matches the actual #if
cc2538: Sort link input sections by alignment to optimize size

Normally, the linker does not sort files and sections matched by wildcards, so
they are placed in the order in which they are seen during link. If numerous
objects with different alignments are mixed, or if objects with unusually large
alignments are present, this very likely leads to a lot of space being wasted
because of accumulated alignment gaps.

This commit forces input sections to be sorted by alignment (unless this is
overridden by the linker script), which decreases the number and the size of
alignment gaps, thus saving space.

For a typical Contiki project, this change saves nearly 1 kiB, mainly in .bss.

Note that this behavior is only enabled if the SMALL make variable is set to 1,
because this makes more sense for a size optimization.

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
cc2538: Move SoC data to a dedicated section to save space

Some SoC data requires huge alignments. E.g., the µDMA channel control table has
to be 1024-byte aligned. This table was simply aligned to 1024 bytes in the C
code, which had the following consequences, wasting a lot of RAM:
 - As this table could be placed anywhere in .bss, there could be an alignment
   gap of up to 1023 bytes between the preceding data and this table.
 - The size of this table was also aligned to 1024 bytes, regardless of
   UDMA_CONF_MAX_CHANNEL, making this configuration option supposed to save RAM
   just useless.
 - .bss was also aligned to at least 1024 bytes, creating a huge alignment gap
   between .data and .bss.

Instead of relying on the compiler to force this alignment, and on the linker to
automatically place data, this change places carefully such SoC data in RAM
using the linker script. A dedicated section is created to place such SoC data
requiring huge alignments, and it is put at the beginning of the SRAM in order
to ensure a maximal alignment without any gap. In this way, the alignment of
.bss also remains normal, and the size of this table is not constrained by its
alignment, but only by its contents (i.e. by UDMA_CONF_MAX_CHANNEL).

In the case of the µDMA channel control table, the data is still zeroed by
udma_init() (instead of also being zeroed as part of .bss).

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>