The use of __FILE__ macro to get a usable identifier from the driver path
causes the path of the file to be stored in the .text region of the binary.
Given that this remains for the entire duration of the program, storing a
pointer to this string as an identifier is more efficient than copying the
contents of the string during lookup/insertion.
Sleep manager tracing strips the path from filenames and uses the result as an
identifier to track drivers that unlock/lock sleep tracing. Replace the function
that strips the path from the string, replace this function with a new macro,
__FILENAME__ which performs the same action in a compiler specific manner.
- GCC_ARM, use __builtin_strrchr which is optimized out at compile time.
- ARM, use __MODULE__ which returns the filename without path.
- IAR, specifiy the --no_path_in_file_macros compiler flag.
The atomic functions preserve volatile semantics - they only perform the
accesses specified. Add the volatile qualifier to the value pointer to
reflect this. This does not change existing caller code - it's
equivalent to adding a const qualifier to indicate we don't write to
a pointer - it means people can pass us qualified pointers without
casts, letting the compile check const- or volatile-correctness.
This is consistent with C11 <stdatomic.h>, which volatile-qualifies its
equivalent functions.
Note that this useage of volatile has nothing to do with the atomicity -
objects accessed via the atomic functions do not need to be volatile.
But it does permit these calls to be used on objects which have been
declared volatile.
The volatile qualifier on the __LDREX/__STREX prototypes only means that
it's safe to use them on volatile objects. Doesn't mean you actually
have to pass them volatile pointers.
Adding the volatile is a bit like doing strlen((const char *) ptr)
because you've got a non-const pointer.
- sector size is 0x800 bytes
- writeable unit size is 0x8 bytes
- flash start address is 0x0
- total ADuCM3029 on chip flash size is 0x40000 bytes
- total ADuCM4050 on chip flash size is 0x7F000 bytes
fix mbed-ci build error L6216E
* (.ARM.exidx) and *(.init_array) must be placed explicitly, otherwise it is shared between two regions, and the linker is unable to decide where to place it.
When exporting to a uvision project, the include flags are not put in
the assembly compilation line. When assembling the files containing
includes, the search path will then fail. This patch adds the include
paths to the Assembly sequence, as it is done for compilation.
This issue was found in the pull request ARMmbed/mbed-os#6168.
Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>
When exporting a mbed project to make_armc5, the include options (-I)
of the ASM flags are not pointing to the good folder. It should be
pointing to the root mbed-os folder and not the one in BUILD.
This issue was found in the pull request ARMmbed/mbed-os#6168.
Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>
bcostm
Christopher Haster
Steven Cartmell
Cruz Monrreal
jeromecoutant
Bartek Szatkowski
Kevin Bracey
li-ho
Mudassar Hussain
zzw
Deepika
David Saada
Jimmy Brisson
Antti Yli-Tokola
Hugues de Valon
Alan Chuang
Teppo Järvelin
Martin Kojtal