Strange gcc warnings with multiboot headers

[Candamir]

I'm booting of GRUB and my assembly code in start.asm looks like this:

Code: Select all

    mov esp, _sys_stack     ; points the stack to our new area
    push eax                ; Multiboot magic number
    push ebx                ; Multiboot info structure
    extern _main
    call _main

And this is my main declaration:

Code: Select all

#include "multiboot.h"

// Stuff ...

int main(multiboot_info_t* mbd, unsigned int magic)
{
   ...

Nevertheless, the compiler gives me these warnings as an output:

Code: Select all

main.c:8: warning: first argument of `main' should be `int'
main.c:8: warning: second argument of `main' should be `char **'

I'm compiling everything with -Wall (and -Werror in all files but main.c, just because of this) and I already googled for the exact warning message(s), but I didn't found anything relevant...

I already tried to push ebx first and eax later, but neither the compiler and the linker change their opinion (the linker actually doesn't say a thing, everything seems correct) and that's why I'm thinking that this problem might originates in something else but not the asm/c combination...

[Colonel Kernel]

Call it something other than "main". "kmain" maybe?

[paulbarker]

A bit of explaination of the above post:

main() is defined by the C Standard for use in user mode programs, so that all C libraries expect main() to look the same. Since you're not writing a user mode program (also known as a "hosted environment") but instead a kernel ("freestanding environment"), you should avoid names like main().

[Candamir]

And is main() the only method affected by this? I mean, lets say I provide a memcpy method different to memcpy(void *dest, const void *src, size_t count); would the compiler also say something? And finally, can I turn this kind of warning of? (Only this warning, not all warnings) Wouldn't it be great to have a gcc hack that permits the option -kernel which automatically selects all the relevant options for kernel development?

[paulbarker]

We all like different options for our kernels .

GCC warns about most (if not all) functions that are defined by the standard. I don't know how to turn these warnings off but I find them useful since re-defining things in the standard will confuse potential contributors. If you will be the only person writing your kernel, do what you like, but if you want people to help with coding, try to keep away from changing standard names.

What I would like is a feature like I saw in MS Visual C++. Each warning had a number and to turn them off you'd just use

Code: Select all

#pragma warning(4000, off)

or something similar. I don't think I'll find that in C though.

[Candamir]

Anyway, I changed my main to kmain, so no problem. But even though, how easy/difficult would it be to hack the gcc code so that if it sees -kernel as an option it replaces it with some other flags before even doing other things. It could be placed in the first few lines of the main method, so that the rest of the compiler wouldn't even know about it. Even if everyone liked his own options, you could just add/remove one line in a single source file (though you had to recompile gcc every time you do this). Has anyone done this before?

[nick8325]

main() is defined by the C Standard for use in user mode programs, so that all C libraries expect main() to look the same. Since you're not writing a user mode program (also known as a "hosted environment") but instead a kernel ("freestanding environment"), you should avoid names like main().

Well, this should lead to the answer

GCC has an option -ffreestanding, which is exactly meant for freestanding environments. The documentation says

Code: Select all

     Assert that compilation takes place in a freestanding environment.
     This implies `-fno-builtin'.  A freestanding environment is one
     in which the standard library may not exist, and program startup
     may not necessarily be at `main'.  The most obvious example is an
     OS kernel.  This is equivalent to `-fno-hosted'.

...and when I try your main() with that flag on, it doesn't complain about it

(p.s. the -fno-builtin flag stops it from treating things like memcpy specially. Otherwise I think it will sometimes replace memcpys with inline assembly moves.)

[paulbarker]

Thats just really confused me. Do the builtins call library functions then?

I want the optimization provided by builtins if possible. Maybe "-ffreestanding -fbuiltin" would do what I want?

If this is going to take more than 2 seconds for you to answer, just direct me to a search. I'm being lazy here.

[nick8325]

Thats just really confused me. Do the builtins call library functions then?

I want the optimization provided by builtins if possible. Maybe "-ffreestanding -fbuiltin" would do what I want?

If this is going to take more than 2 seconds for you to answer, just direct me to a search. I'm being lazy here.

It looks like they can call the library functions. GCC treats them specially, though - I just tried a call to __builtin_memcpy, and with -O0 it compiles into a rep movsb, but with -O it compiles into a call to memcpy.

I tried -ffreestanding -fbuiltin, and it seems to do the trick. But with -fbuiltin, GCC is picky about the types of the builtin functions, and will complain if you declare it to have a slightly different type from the one it expects.

[paulbarker]

I'm currently using the string functions from PDCLib in my kernel (only the simple ones), which look close enough to the standard to me. Using builtins would certainly speed up memcpy.

I'll give it a shot.

[Solar]

I'm currently using the string functions from PDCLib in my kernel (only the simple ones), which look close enough to the standard to me.

They should, as they were written using the ISO/IEC 9899:1999 document as reference.

Using builtins would certainly speed up memcpy.

I would expect so, as the PDCLib code is (for now) 100% generic, whereas GCC builtins are highly optimized to the platform.

Later versions of PDCLib (try 1.0...) will provide an option to use GCC builtins, but that's left for when the generic code is complete (which it isn't by a long shot yet).