On 24/11/2020 16:08, Michael Grunditz wrote:
Odd but when 8 mmap areas created malloc doesn't use heap, but produces
a crash.
Checked now.. there is no mmap call. But the problem might be something else.
If I hardcode a insane amount of stack , the mallocs uses heap , to a
much higher extent.
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.
I did a unscientific test. Malloc 12 bytes , fill with 16 bytes, which
worked , so malloc is 8 byte aligned.
Maybe just lucky shot .. filling with 18 bytes , gives me bad mem at the end.
Sorry, I think we might have our wires crossed :-) It's the address
returned by malloc that needs to be 8 byte aligned rather than the
number of bytes returned.
The problem is, some instructions, for example LDRD, require an 8
byte aligned base address. If we use malloc to allocate a structure
that starts with an 8 byte type that the compiler might use LDRD to
load and malloc returns a 4 byte (but not 8) aligned address, then it
will probably abort.
In fact, I fell foul of something similar in the dynamic linker
when porting GCC 8/10; I had to ensure that the library data segments
retained the original alignment that the compiler/linker gave them to
prevent LDRD from aborting.
I suspect that newer versions (than 4.7) of GCC will expect malloc'ed
memory to be 8 byte aligned and pad structures accordingly.
Unfortunately, we're a bit behind there, and I think it is something we
need to look at.
Lee.
_______________________________________________
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
