On 23/11/2020 13:49, Michael Grunditz wrote:
Den sön 22 nov. 2020 12:25Lee Noar <lee.n...@sky.com
<mailto:lee.n...@sky.com>> skrev:
On 21/11/2020 22:40, Michael Grunditz wrote:
> Hi
>
> Is there any way to not get MMap areas from malloc()?
Currently, no, malloc is compiled to use mmap for allocation requests of
256KB (I think) or more, but Unixlib only allows 8 mmap areas to be in
use at one time. If there are already 8 mmap areas in use, then malloc
will use the heap.
Odd but when 8 mmap areas created malloc doesn't use heap, but produces
a crash.
Are you sure that mmap isn't being called directly somewhere else after
all 8 areas have been used? Just checked the code for malloc, and
it does check what's returned by mmap and continues on with app space
allocation if it's NULL.
If you see a crash in malloc after 8 mmap areas are created, can you
reduce it to a small test case?
Not a gccsdk question ( I think) but is malloc(n) supposed to return
address aligned to n?
No, n is the number of bytes you require. We do have memalign(),
although I'm not sure if it's exported in the headers.
I believe, off the top of my head that, malloc should return an address
aligned to the host machine's pointer size, so 4 byte alignment for
32bits and 8 byte alignment for 64bits. Having said that, that doesn't
account for double word loads that may require 8 byte alignment. It's
quite possible that our malloc should be returning 8 byte aligned
addresses to account for new processor requirements, I should probably
look into that.
Thanks,
Lee.
(PS. Apparently, x86 64bit uses 16byte alignment for malloc).
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK