Dear Graeme Russ,
In message CALButCK7CxJy6fg8Ym2Ao8tVrD5HTihGWaV+TF8Y9qNe62MnFw@mail.gmail.com you wrote:
I pointed out that those pointers can only by in either GD or the early malloc heap. But either way, there is no generic way to adjust them. Any code that uses the early malloc heap and wants to retain that data for use after relocation will need to implement it's own relocation code.
Having a specific early_malloc() has the advantage of being explicit. The
Yes, and we need this explicity to make sure the caller knows which behaviour he can expect. Actually, a standard malloc() should either work reliably or cause build time errors.
That was never how I thought about it. Anything that uses the early heap needs to 'help' the relocation process. My thought was to make the glue logic for the helper as seamless as possible.
I agree with that.
Because you cannot track which pointers point into it. They can be
Yes
distributed all over the code. Any function anybody calls might use malloc() internally, and keep static pointers to allocated data.
No - There can be no static pointers before relocation - All pointers must be in either GD or in structures allocated on the early malloc heap
Thanks for correcting me. That was what I actually meant - the effect is the same.
So to summarise:
- Early malloc() needs to be a malloc()
Um... no! malloc() is suposed to behave in standard way, without any expectations that pointers to storage retured by malloc() will ever have to be relocated or such.
For early malloc, a function with a different name shall be used.
Best regards,
Wolfgang Denk