임베디드 시스템에서 CodeSourcery 사의 arm-none-eabi 툴체인 사용시 page size가 4kB으로 되어 있다. 하지만 stm32f10x의 메모리는 보통 20kB 많아도 68kB다 이러한 상황이니 page size를 작게 변경하거나 malloc()대신 _malloc_r을 사용한다고 되어 있다만, 소스코드를 일일이 변경해야 하고 다른 시스템에서 다시 복구해야하는 문제점이 발생한다. 그래서 arm-none-eabi의 libc로 사용중인 newlibc의 page사이즈를 재설정하고 다시 컴파일해야한다. 하지만, 그리 간단한 일이 아닌가 보다. 다음과 같은 해답을 구했다.
> The mallocr.c from the newlib-source checks a define SMALL_MEMORY which
> sets the alignment to 128.
>
> Which sounds more reasonable.
>
> But I think this sbrk() stuff is quiet needles for system w/o virtual
> memory where the size of the heap is fixed at link-time.
그리고 _malloc_r에 대해서 찾아 보았다.
The _malloc_r routine is indeed a version of malloc which uses an additional
parameter to receive a reentrancy structure. The malloc routine simply calls _malloc_r with
the default reentrancy structure. Internally, any reentrant library routines must
call _malloc_r instead of malloc and pass whichever reentrancy structure was
passed to them. Thus, you want to replace the _r interfaces rather than the
top level routines like malloc() and free().
Multithreaded applications must create their own separate reentrancy structures per
thread and must use _r routines where provided. For more information, see the
library info files (make info install-info). You can alternatively peruse the info source
for the reentrancy chapter in newlib/libc/reent directory (reent.tex).
A while back, _malloc_r used to use manage heap storage from pools that were
stored off of the reentrancy structure. Now, the reentrancy structure is used
as a mutex identifier for __malloc_lock and __malloc_unlock. By default,
__malloc_lock and __malloc_unlock are only provided as stubs.
If you don't need to worry about multithreaded applications using your malloc,
simply create versions of _malloc_r, _free_r, _calloc_r, and _realloc_r that
ignore the reentrancy structure. Otherwise, you will have to either use
a mutex system (and supply mutex routines) or use a separate pool per reentrancy
structure.
아 모르겠다. 어쩌라는 건지?
댓글 없음:
댓글 쓰기