summaryrefslogtreecommitdiff
path: root/core/cortex-m0/vecttable.c
Commit message (Collapse)AuthorAgeFilesLines
* LICENSE: remove unnecessary (c) after CopyrightTom Hughes2019-06-191-1/+1
| | | | | | | | | | | | | | | | Ran the following command: git grep -l 'Copyright (c)' | \ xargs sed -i 's/Copyright (c)/Copyright/g' BRANCH=none BUG=none TEST=make buildall -j Change-Id: I6cc4a0f7e8b30d5b5f97d53c031c299f3e164ca7 Signed-off-by: Tom Hughes <tomhughes@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1663262 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* cortex-m0: Generate vector table in CPatrick Georgi2018-10-161-0/+136
Different versions of the linker behave differently when mixing object built with lto enabled (desirable for code size reduction) and disabled (assembler code), especially when they refer to each other symbols: The file evaluation order of the linker becomes important as it eliminates dead code at various points in time, and LTO code referring to non-LTO code or vice versa, is not visible at early runs. Sadly, just changing the order on the command line isn't sufficient: What works for gcc8 breaks gcc6 (and may behave different in even more ways on gcc4 or other versions). Therefore, implement the vector table in C, so it's compiled in LTO mode, just like the code it refers to. This is a port of Change-Id: I9b75f6558f0357e18000ff1161096c8f9c94a8ac BUG=b:65441143 BRANCH=none TEST=with this change the vector table for whiskers looks much more reasonable (ie. not mostly empty) Change-Id: Ifd39289ecb16b81cdf41427ce190984510d3fd3c Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://chromium-review.googlesource.com/1120333 Commit-Ready: Patrick Georgi <pgeorgi@chromium.org> Tested-by: Patrick Georgi <pgeorgi@chromium.org> Tested-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1177382 Reviewed-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org>