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
