Is it OK to link libgcc.a to my OS kernel?

[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

[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.

[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.

[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.

[yuq]

I think my question can be summarized into:

Is libgcc OS dependent?

[OSwhatever]

I think my question can be summarized into:

Is libgcc OS dependent?

Not the version I'm using at least (the os-free eabi).

[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.

[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).

[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.

[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);
}

[Combuster]

Think about it, how much time would that function take to divide a 6-digit number by 3? Does it even do that?

[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

[bluemoon]

Try long division using shift and sub. It's not fastest but faster than subtraction loops.

[Combuster]

btw i got 50% from here:

http://wiki.osdev.org/ARM_Overview#ARM_ ... r_Division

*poof*

Never happened

[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