OSDev.org

Posted: **Thu Sep 15, 2005 3:04 am**

Hi,

I'm just starting out with OS dev and before I start making a real OS, I tried to make a small test based on "Bran's Kernel Development", which is really comprehensive and stuff, but it keeps giving me "Invalid or unsupported executable format" when I tried to boot it from a grub floppy or with bochs. I've only implemented everything up to the video stuff. I'm using gcc version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1), NASM version 0.98.39 compiled on Sep 12 2005 and GNU ld version 2.16.1 on a Linux system.

Posted: **Thu Sep 15, 2005 3:08 am**

That definitely sounds like a missing multiboot header or a poorly configured compilator environment. Check out

http://www.osdev.org/osfaq2/index.php/BareBones

That should help you setting robust basis between your work and GRUB.

Posted: **Thu Sep 15, 2005 3:26 am**

After changing the assembly, the linker script and the gcc lines in my build script, gcc outputs:

Code: Select all

compiling the kernel:In file included from main.c:1:
system.h:4: warning: conflicting types for built-in function `memcpy'
system.h:5: warning: conflicting types for built-in function `memset'
system.h:16: warning: conflicting types for built-in function `puts'

it shouldn't use built in functions now should it? ???

I've added "-fno-builtin" and that solves the problem, but shouldn't this be used in the FAQ?

Posted: **Thu Sep 15, 2005 4:26 am**

*rofl*

Lad, you can as well add it to the FAQ if you consider it crucial. Just edit as you think without turning the whole thing into a pile of turd. Be happy.

stay safe.

Posted: **Thu Sep 15, 2005 5:54 am**

just to be sure, what kind of definition of "memcpy" do you use ? it may happen that the compiler isn't pleased with your headers: it was about to use its own internal (and efficient, already available, etc.) implementation of memcpy for internal purpose (e.g. copying a structure into another), but it discovered something odd instead of

Code: Select all

       void *memcpy(void *dest, const void *src, size_t n);

and thus it complained.

Posted: **Thu Sep 15, 2005 2:57 pm**

my function uses int instead of size_t, but size_t is just defined as an int anyway isnt it? I thought you shouldn't use any standard functions, as they are not available for kernel development, but these basic ones are allowed?

Posted: **Thu Sep 15, 2005 11:33 pm**

Hi,

yukito wrote:my function uses int instead of size_t, but size_t is just defined as an int anyway isnt it? I thought you shouldn't use any standard functions, as they are not available for kernel development, but these basic ones are allowed?

I'm not sure about C's type checking.

IMHO some standard C library functions should have been included as part of the C language and never implemented in a library at all. Of these I'd include rawmemchr(), memset() and memcpy(), and probably a few more.

The reason for this is so that the optimizer can optimize. For example, if you do:

Code: Select all

const char the_string[] = "This string ends up in the .rodata section and is never changed.";

int string_length_example(void) {
    return rawmemchr(the_string, 0);
}

Then it'd be nice if it compiled to the following assembly:

Code: Select all

_string_length_example:
    mov eax,64
    ret

This is much faster than using a generic library routine that would need to search the string at run time.

The same sort of thing can apply to memset() and memcpy(). For example:

Code: Select all

%define array_elements   5

int arrayA[array_elements];
int arrayA[array_elements];

void copy_arrayA_to_arrayB(void) {
    memcpy(arrayB, arrayA, array_elements * sizeof(int) );
}

Because the compiler can figure out that both arrays are always aligned and always have the same size, this could become:

Code: Select all

_copy_arrayA_to_arrayB:
    mov esi,_arrayA
    mov edi,_arrayB
    movsd
    movsd
    movsd
    movsd
    movsd
    ret

Again, this would be much faster than a generic library routine (the generic routine would need to work on any number of bytes regardless of whether they are aligned or not, or if the number of bytes to copy is a multiple of 4 or not).

I'm not a C expert, and I don't know how good each compiler/optimizer/library is, but I assume that optimizations like this are the reason why GCC has these functions built in, which makes me think it's better to use the built in functions if possible.

Cheers,

Brendan

OSDev.org

Grub error 13

Grub error 13

Re:Grub error 13

Re:Grub error 13

Re:Grub error 13

Re:Grub error 13

Re:Grub error 13

Re:Grub error 13