Page 1 of 2
Is it OK to link libgcc.a to my OS kernel?
Posted: Wed Jul 13, 2011 2:28 am
by yuq
Hello everyone:
I'm writing an OS kernel for ARM platform. It seems ARM doesn't have unsigned int divide and mod instruction so that GCC call "__aeabi_uidiv()" and "__aeabi_uidivmod()" in libgcc. I try to link libgcc.a into my kernel, but GCC report it can't find "raise" symbol. I find it is a function to raise divided-by-zero exception, but I don't know where this function is (in libc?). So I wonder if libgcc is OS dependent. If so, I think I should not link libgcc into my kernel and write the above two function myself or from libgcc source code. I also wonder what Linux kernel do, is these functions in Linux kernel source code too?
Regards,
Yu Qiang
Re: Is it OK to link libgcc.a to my OS kernel?
Posted: Wed Jul 13, 2011 2:35 am
by blobmiester
Hello yuq,
Are you properly using a cross compiler, as instructed by
GCC_Cross-Compiler? There is a section in there about building libgcc.a as well.
Assuming you are, and libgcc.a really does need this raise symbol (I've never attempted to use libgcc.a as I don't care for GPL) then you can provide it quite simply. The raise symbol it refers to is likely the standard raise function described in ยง7.14 of the International Standard C standard (part of the signal.h header) which is fairly trivial to implement. If you encounter any trouble with the implementation, please be sure to cite exactly what trouble you're having.
Re: Is it OK to link libgcc.a to my OS kernel?
Posted: Wed Jul 13, 2011 2:55 am
by yuq
Hello blobmiester:
I'm not using a cross-compiler. I compile my kernel in an ARM computer locally. It is Ubuntu 11.04 for OMAP4430 pandaboard, so I think the GCC and libgcc is OK.
You said the "raise" is a standard C function, so it is OS dependent right? And consider the OS dependent "raise" function is not in libgcc, so libgcc is OS independent and I can link it into my OS kernel and just implement some OS dependent function libgcc calls?
Is Linux kernel link libgcc into it too and just do like above or implement libgcc functions itself? I've even seen Linux kernel implement 64bit divide function in its source for x86 32bit computer.
Re: Is it OK to link libgcc.a to my OS kernel?
Posted: Wed Jul 13, 2011 3:05 am
by OSwhatever
libgcc is pretty much required if you want to get anywhere with your code. It contains a lot of compiler and architecture specific help code like the division code for example.
Linux have many own implementations of the very basic stuff so if it use libgcc at all, it is probably done very sparsely.
Re: Is it OK to link libgcc.a to my OS kernel?
Posted: Wed Jul 13, 2011 3:16 am
by yuq
I think my question can be summarized into:
Is libgcc OS dependent?
Re: Is it OK to link libgcc.a to my OS kernel?
Posted: Wed Jul 13, 2011 3:54 am
by OSwhatever
yuq wrote:I think my question can be summarized into:
Is libgcc OS dependent?
Not the version I'm using at least (the os-free eabi).
Re: Is it OK to link libgcc.a to my OS kernel?
Posted: Wed Jul 13, 2011 3:57 am
by Owen
Maybe. All bets are off if you're using a libgcc built for Linux.
Build libgcc (Or LLVM compiler-rt) for your target platform. The easiest way to do this is to build a cross compiler.
In OS development, a cross compiler is useful anyway, whether you're targeting a different architecture or not. Plus, you gain the advantage that you don't need to boot into Linux during you testing cycle; you just send the code over to the development board.
Re: Is it OK to link libgcc.a to my OS kernel?
Posted: Thu Jul 14, 2011 1:16 am
by xyzzy
I'm using a cross-compiler to build my kernel for ARM (custom target using EABI) and even then libgcc is using some external functions for signalling error conditions, such as abort(). I've just implemented these as a call to fatal() (equivalent to panic in my kernel).
Re: Is it OK to link libgcc.a to my OS kernel?
Posted: Thu Jul 14, 2011 2:31 am
by yuq
So it seems libgcc itself is OS independent except for calling some function OS provides.
I find Linux kernel source has "__aeabi_uidiv" and "__aeabi_uidivmod" functions.
I think I have two choices:
1). Implement some libgcc functions like Linux kernel.
2). link libgcc into my kernel and implement functions libgcc calls.
Re: Is it OK to link libgcc.a to my OS kernel?
Posted: Tue Jul 03, 2012 11:53 pm
by cycl0ne
Code: Select all
.globl __aeabi_uidivmod
__aeabi_uidivmod:
stmfd sp!, {r0, r1, ip, lr}
bl __aeabi_uidiv
ldmfd sp!, {r1, r2, ip, lr}
mul r3, r0, r2
sub r1, r1, r3
mov pc, lr
and
Code: Select all
unsigned int __aeabi_uidiv(unsigned int num, unsigned int den)
{
unsigned int x;
for (x = den; x < num; x += den);
return x;
}
int __aeabi_idiv(int num, int den)
{
return __aeabi_uidiv(num, den);
}
Re: Is it OK to link libgcc.a to my OS kernel?
Posted: Wed Jul 04, 2012 2:17 am
by Combuster
Think about it, how much time would that function take to divide a 6-digit number by 3? Does it even do that?
Re: Is it OK to link libgcc.a to my OS kernel?
Posted: Wed Jul 04, 2012 3:22 am
by cycl0ne
Dunno, ARM sucks
Better suggestion for those two Functions?
btw i got 50% from here:
http://wiki.osdev.org/ARM_Overview#ARM_ ... r_Division
Re: Is it OK to link libgcc.a to my OS kernel?
Posted: Wed Jul 04, 2012 3:38 am
by bluemoon
Try long division using shift and sub. It's not fastest but faster than subtraction loops.
Re: Is it OK to link libgcc.a to my OS kernel?
Posted: Wed Jul 04, 2012 4:04 am
by Combuster
*poof*
Never happened
Re: Is it OK to link libgcc.a to my OS kernel?
Posted: Wed Jul 04, 2012 5:24 am
by JamesM
Hi,
Perhaps I can shed some light on this
libgcc.a, and LLVM's compiler-rt, provide support functions. The compiler will generate code assuming one of these is available - some of these support functions are ABI-defined, and some are defined on the whim of the compiler developer - the interaction between compiled code and the compiler support library is implementation defined.
So you should always link libgcc.a into your kernel, else you'll end up with undefined symbols.
As to ARM not having native divide, if you're compiling for ARMv7A (for example ARM1176, Cortex-A8, Cortex-A9), the UDIV and SDIV instructions are available. Ensure you're using the correct -mcpu= or -march= flags in your compile line.
Any more problems reply here and I'll try and help.
Cheers,
James