Previously, exception stubs had to be declared in assembly
language files. Now we have two new APIs to regsiter exception
handlers at C toplevel:
_EXCEPTION_CONNECT_CODE(handler, vector)
_EXCEPTION_CONNECT_NOCODE(handler, vector)
For x86 exceptions that do and do not push error codes onto
the stack respectively.
In addition, it's now no longer necessary to #define around
exception registration. We now use .gnu.linkonce magic such that
the first _EXCEPTION_CONNECT_*() that the linker finds is used
for the specified vector. Applications are free to install their
own exception handlers which will take precedence over default
handlers such as installed by arch/x86/core/fatal.c
Some Makefiles have been adjusted so that the default exception
handlers in arch/x86/core/fatal.c are linked last. The code has
been tested that the right order of precedence is taken for
exceptions overridden in the floating point, gdb debug, or
application code. The asm SYS_NANO_CPU_EXC_CONNECT API has been
removed; it was ill- conceived as it only worked for exceptions
that didn't push error codes. All the asm NANO_CPU_EXC_CONNECT_*
APIs are gone as well in favor of the new _EXCEPTION_CONNNECT_*()
APIs.
CONFIG_EXCEPTION_DEBUG no longer needs to be disabled for test
cases that define their own exception handlers.
Issue: ZEP-203
Change-Id: I782e0143fba832d18cdf4daaa7e47820595fe041
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Use SOC_FAMILY and SOC_SERIES to identify soc families and series
and to point to the correct linker files and files related to a
specific SoC.
Change-Id: I8b1a7339f37d6ea4161d03073d36557a40c0b4a6
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The GDB server implements a set of GDB commands, such as read/write
memory, read/write registers, connect/detach, breakpoints, single-step,
continue. It is not OS-aware, and thus provides a 'system-level'
debugging environment, where the system stops when debugging (such as
handling a breakpoint or single-stepping).
It currently only works over a serial line, taking over the
uart_console. If target code prints over the console, the GDB server
intecepts them and does not send the characters directly over the serial
line, but rather wraps them in a packet handled by the GDB client.
Change-Id: Ic4b82e81b5a575831c01af7b476767234fbf74f7
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
Change terminology and use SoC instead of platform. An SoC provides
features and default configurations available with an SoC. A board
implements the SoC and adds more features and IP block specific to the
board to extend the SoC functionality such as sensors and debugging
features.
Change-Id: I15e8d78a6d4ecd5cfb3bc25ced9ba77e5ea1122f
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Avoid having to remove quotes wherever the platform name is used
by exporting the variable only once.
Change-Id: I4cb51901e4ac19d70d0310fe6bbacd157f586661
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Do not depend on host architecture and use architecture definition
from the defconfig file of the board.
Change-Id: Idb3dd42524f26bd167a34d6eb024d4d9816e9730
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Do not reference every platform, instead use the platform
name to tell make what to build.
Change-Id: I7498da7cdcdada754466222902f59fe4c6487d89
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The Intel Quark microcontroller D2000, is a low power, battery-operated,
32-bit microcontroller. Within its small footprint, the Intel Quark
microcontroller D2000 includes an Intel Quark ultra-low-power core
running at 32 MHz, with 32k integrated flash and 8k OTP SRAM.
Change-Id: I6ba121996edb0b5fbe596bd6ef3d6e3979ff73e9
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Follow the model of the Linux kernel for adding arch
specific CFLAGS by using the Makefile and Kbuild combination
in the arch/<arch> directory.
This will also allow adding architecture specific targets and is
easy to maintain when alongside the architecture.
Change-Id: If51a78e8845baa71d9090c4a4f49fcd013354840
Signed-off-by: Anas Nashif <anas.nashif@intel.com>