Re: [gccsdk] malloc

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