Issue #176: avoid recursive call on allocator on library initializaton

[VGubarev]

This PR solves issues #98 and #176.

First, libcoz must provide basic allocator via malloc/calloc (for dlsym) to avoid clash with user' allocator like jemalloc

Second, libcoz must be preloaded before any other to override any other allocator implementation

Third, once libcoz is initialized (right before real main) disable internal allocator and pass requests through

[VGubarev]

Closed as another approach proposed in concurrent PR

[kormang]

Hi, sorry for late answer.

1. AFAIR, COZ is initialized right before user main. By this time, all the statics (including allocator) are initialized by runtime. So dummy implementaton will be disabled by the time program enters its own main.
2. I assumed only allocations matter and must be preserved. Stub deallocation does not affect program in any way.
3. Didn't really get your point on bug in dummy allocator as your program has similar implementation.
4. I'm really obsessed of talks about (non)predictable indirrect call vs (non)predictable branch but when we're talking about malloc it just does not make any sense to discuss because malloc itself is extremely expensive when compared to our subject.

1. As far as I understand your code, you own implementation works until initialization of coz starts. After coz starts initializing, real malloc implementation kicks in. I wouldn't count on all programs to never allocate memory before coz starts initialization, including coz itself.
2. Also, I wouldn't count that memory allocated by your own implementation never gets freed later, when coz is initialized and switched to real free. In such case real free will receive address that is allocated by your own implementation.
3. Well, I assume that a lot of things can go wrong, with my implementation too. That's why I'd like to make it optional. As far as you implementation is concerned, I assume that it is possible in some situations, that real free receives address allocated by your malloc. For example, a library's constructor might allocated some memory, before coz initiazliation starts, and some other code might free it after coz initialization has started. I'm not even sure why exactly you have choosen coz initialization start as point when you switch to real malloc? It might work, but how can you prove that it would always be correct?
4. You are right, it is not significant.

[VGubarev]

Thank you, @kormang! I appreciate your answer a lot and thank you for your time!

Hi, sorry for late answer.

1. As far as I understand your code, you own implementation works until initialization of coz starts. After coz starts initializing, real malloc implementation kicks in. I wouldn't count on all programs to never allocate memory before coz starts initialization, including coz itself.
2. Also, I wouldn't count that memory allocated by your own implementation never gets freed later, when coz is initialized and switched to real free. In such case real free will receive address that is allocated by your own implementation.
3. Well, I assume that a lot of things can go wrong, with my implementation too. That's why I'd like to make it optional. As far as you implementation is concerned, I assume that it is possible in some situations, that real free receives address allocated by your malloc. For example, a library's constructor might allocated some memory, before coz initiazliation starts, and some other code might free it after coz initialization has started. I'm not even sure why exactly you have choosen coz initialization start as point when you switch to real malloc? It might work, but how can you prove that it would always be correct?
4. You are right, it is not significant.

1. Actually dummy implementation works until COZ init has finished. And it gets finished right before user' main.
2. That's fair point. Agree, it may corrupt an allocator.
3. Optionality is really good idea, totally agree here. About dummy malloc vs real free -- good point from p.2.