Note: dlsymtab is not in standards. but just in case.
(gdb) bt
#0 getpid () at task/task_getpid.c:91
#1 0x00000000004fbc9d in modlib_registry_lock ()
at modlib/modlib_registry.c:89
#2 0x0000000000719ee0 in modsym (handle=0xffffffffffffffff,
name=0x7fa7ebdde8c7 "mmap") at module/mod_modsym.c:92
#3 0x000000000071597d in dlsym (handle=0xffffffffffffffff,
name=0x7fa7ebdde8c7 "mmap") at dlfcn/lib_dlsym.c:164
#4 0x00007fa7ebdbeb39 in ?? () from /lib/x86_64-linux-gnu/libasan.so.5
#5 0x00007fa7ebd79b28 in ?? () from /lib/x86_64-linux-gnu/libasan.so.5
#6 0x00007fa7ebd9d7a7 in ?? () from /lib/x86_64-linux-gnu/libasan.so.5
#7 0x00007fa7ec6ce03a in ?? () from /lib64/ld-linux-x86-64.so.2
#8 0x00007fa7ec6ce141 in ?? () from /lib64/ld-linux-x86-64.so.2
#9 0x00007fa7ec6be13a in ?? () from /lib64/ld-linux-x86-64.so.2
#10 0x0000000000000001 in ?? ()
#11 0x00007fff028f686b in ?? ()
#12 0x0000000000000000 in ?? ()
(gdb) quit
PR #1450 broke the Cygwin build. Refer to Issue #1672.
The use of of logic like:
EXTRA_LIBPATHS += -L "${dir ${shell $(CC) $(ARCHCPUFLAGS) --print-file-name=libgcc.a}}"
fails when the Toolchain $(CC) is a native Windows toolchain. That is because the returned path is a Windows-style patch which cannot be handled by the make 'dir' command. Commit 4910d43ab0 reorganized a lot of definitions and replaced the correct code with the use of the limit make 'dir' command. The original code used the Bash dirname command which does not suffer from this limitation; it can handle both POSIX and Windows paths.
This was verified using the stm32f4discover:nsh toolchain with the Windows native ARM Embedded toolchain. That toolchain returns:
arm-none-eabi-gcc --print-file-name=libgcc.a
c:/program files (x86)/gnu tools arm embedded/9 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/libgcc.a
Comments only. No functional changes. See STM32G474 Reference Manual
(RM0440 Rev 4), section 3.4.1, Table 11, "Option byte organization."
arch/arm/src/stm32/hardware/stm32g47xxx_memorymap.h:
* STM32_OPTION_BASE: The comment incorrectly said the range was
0x1fff7800-0x1fff780f for a total of 16 Option Bytes. Corrected
this to 0x1fff7800-0x1fff782f, as the device has 48 Option Bytes
for this option block.
* STM32_OPTION_BASE2: The comment incorrectly said the range was
0x1ffff800-0x1ffff80f for a total of 16 Option Bytes. Corrected
this to 0x1ffff800-0x1ffff82f, as the device has 48 Option Bytes
for this option block.
Summary:
- This commit improves SPI performance.
- For small data, it does not use DMA.
Impact:
- All use cases which use SPI with DMA
Testing:
- Tested with spresense:wifi and spresense:example_lcd
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
