nexos wrote:That wouldn't be a good idea. Why waste time writing functions GCC provides for you, when your implementation will be slower and probably have bugs?
Look at this thread. The OP has now spent a few days recompiling the compiler to get it to work with a higher half kernel. The cumulative time of reimplementing some simple functions and the lost time from their execution not being as fast as it could be could never equal that.
Plus, on AMD64, there is very little that libgcc provides that is of use to a kernel in any case. 64-bit division is supported natively, kernels don't use floating-point, and a C kernel doesn't need the exception-handling stuff for C++. On the contrary, it seems here that libgcc was adding code nobody wanted or needed, and then failed at doing even that.
Also, what do we do against bugs? We test the code. And libgcc code is very easy to test, you can just put it into a userspace application (maybe rename the functions), then run test vectors against the code. We do not throw our hands up in exasperation and wonder how the world could ever get better.
My stance is that kernel code is very special, and gcc's way of dealing with having to compile libgcc with special flags is too cumbersome to be useful (as evidenced by this thread, again), and the gain is minimal, at least for C. Most libgcc code is not written to account for the special needs of a kernel (e.g. the need to avoid libc calls, or even just to avoid non-integer registers), and that too is something you can affect with your own implementations. I had been looking a lot into C++ exception handling lately, and wouldn't you know it, of course the supporting code calls malloc() and accesses the XMM registers. Which is fine in userspace, but in kernel space it is forbidden.
And usually, a simple implementation (that is correct!) can be found and tested. Yeah it won't be as fast as the released version, but who cares? The routines typically found in libgcc are hardly the typical bottlenecks in kernel code.
nexos wrote:My recommendation to the OP: compile with -mcmodel=large instead -mcmodel=kernel. Basically, this doesn't restrict where code or data go. It will be a lot simpler.
And there goes your credibility as paragon of velocity. The large model is incredibly inefficient, since every memory reference must be loaded into a register first, even jump and call labels. Didn't you care about speed just one sentence earlier? The large model does have PIC support, but I am unsure whether it will need runtime support in order to work, and as you recall, PIC was the sticking point in the GCC build system.
.
.
