+CC Claudiu On 10/27/2016 02:39 AM, Alexey Brodkin wrote: > > And these are functions required by U-Boot (most probably the same is applied to kernel): > 1) so-called millicode, stuff like __ld_rX_to_rY, __st_rX_to_rX This kicks in only at -Os and even there can be inhibited with a toggle. I don't like it anyways, seems like a costly contraption in terms of microarch cost of 2 extra long branches for both prologue and epilogue. > 2) shifts: __ashldi3, __ashrdi3, __lshrdi3, > 3) divisions: udivmodsi4, __divsi3, __modsi3, __udivsi3, __umodsi3 Note that this list is not constant. I recently had to export another libgcc symbol for modules, when a customer switched to ARC gnu 2016.03 for supposedly building the same kernel code. > Indeed it is possible to have so-called private libgcc in kernel as well but > benefit will be only for people building kernels but not user-space because > in absence of multilibbed toolchain 2 separate toolchains will be required anyways. True, but a lot of people only care about builds (and not actually run), so for them having to carry only one toolchain is an improvement. > Still we'll have to pay an additional maintenance price to keep kernel's libgcc in > sync with the one from gcc. True, but libgcc math emulation is likely one off thing. GNU folks will write them once and we use a snapshot - syncing back changes - if any around major gnu releases. So I'm tending to include the libgcc code in kernel. @Arnd, @Claudiu do you know of any potential licensing issues ? -Vineet
