Bug when printing...

[benjii]

Okay, so today I decided to print stuff like "Enabling a20, setting up gdt" etc. and I came up with a really strange bug which I couldn't fix in any way...



First three lines are printed in assembly code. The fourth line is printed in C code with my printf function. The thing is, that if I don't print the last line, the first line doesn't have that space at the beginning. I have totally no idea how that space appears at the beginning of the first line -- it shouldn't be there, obviously. This is how I print the fourth line:

Code: Select all

_printf("%b[CPU] Remapping PIC and enabling interrupts... \n");

'%b':

Code: Select all

case 'b':
    y = (*(int *)0x450) + 1;
    screen_idx = y*80 + x;
    x = 0;
break;

I've saved the value of Y position at 0x450 address when I've finished printing stuff in assembly code like that:

Code: Select all

mov al, byte[CurY]
mov [0x450], al

The value of Y is correct. If you need any additional information -- tell me, I'll provide it.

Regards,
--benjii

[Griwes]

Note: `int` does not have the same size as `byte`.

[benjii]

Note: `int` does not have the same size as `byte`.

Nice catch, but that unfortunately didn't solve my problem...

[Combuster]

First three lines are printed in assembly code. The fourth line is printed in C code with my printf function.

And I assume it's in that order? My crystal ball suggests your linking is off and it executes stray printf code before entering your bootstrap... Can you post the commands you use to compile, link and build your image? Include linker scripts if you have them.

[benjii]

First three lines are printed in assembly code. The fourth line is printed in C code with my printf function.

And I assume it's in that order? My crystal ball suggests your linking is off and it executes stray printf code before entering your bootstrap... Can you post the commands you use to compile, link and build your image? Include linker scripts if you have them.

Uhm, fortunately the order is correct. How I compile:

Code: Select all

----------ASM----------

nasm loader/booter/bootsector.asm -f bin -o bootsector
nasm loader/booter/stage2.asm -f bin -o stage2.bin
nasm loader/booter/idt.asm -f elf -o idt.o
 
----------C----------
 
gcc loader/booter/i386.c -c -m32 -nostdlib -nostartfiles -nodefaultlibs -I include -o i386.o
gcc loader/booter/pic.c -c -m32 -nostdlib -nostartfiles -nodefaultlibs -I include -o pic.o
gcc loader/booter/main.c -c -m32 -nostdlib -nostartfiles -nodefaultlibs -I include -o main.o
gcc clib/printf.c -c -m32 -nostdlib -nostartfiles -nodefaultlibs -I include -o printf.o
gcc clib/string.c -c -m32 -nostdlib -nostartfiles -nodefaultlibs -I include -o string.o
gcc clib/stdlib.c -c -m32 -nostdlib -nostartfiles -nodefaultlibs -I include -o stdlib.o
 
----------LD----------
 
ld printf.o stdlib.o string.o i386.o idt.o pic.o main.o -m elf_i386 -e main -T link.ld --strip-all -o stage2.elf

And my linker script:

Code: Select all

    ENTRY (main)
    SECTIONS {
        . = 0x100000;          
        .text : {
            *(.text)
        }
        .data : {
            *(.rodata)
            *(.rdata)
            *(.data)
        }
        .bss : {
            *(.bss)
        }
        /DISCARD/ : {
            *(.comment)
        }
    }

P.S. I tried adding magic breakpoint before calling printf function, but that damn space was already there... So I couldn't get anything useful from debugger.

[Combuster]

1) I see a 64-bit Linux host and a lack of a crosscompiler... And especially since you're using "main" (special name!), there will probably be setup code added that you don't find in regular functions.

2) I also see an ELF-formatted kernel binary combined with a custom bootstrap, of which I'm guessing doesn't know what ELF is.

3) And there's that magic printf.o coming first on the command line, which often means it is also the first thing in the binary, and hence the first thing getting executed assuming I'm right about part 2.

4) The entry point is in C land. That means your second stage must be taking care of everything C need, including all segment registers and a valid ESP.

P.S. I tried adding magic breakpoint before calling printf function, but that damn space was already there...

Put your magic breakpoint just before leaving stage2, then go figure where it actually ends up, you'll probably be surprised

[benjii]

1) I see a 64-bit Linux host and a lack of a crosscompiler... And especially since you're using "main" (special name!), there will probably be setup code added that you don't find in regular functions.

2) I also see an ELF-formatted kernel binary combined with a custom bootstrap, of which I'm guessing doesn't know what ELF is.

3) And there's that magic printf.o coming first on the command line, which often means it is also the first thing in the binary, and hence the first thing getting executed assuming I'm right about part 2.

4) The entry point is in C land. That means your second stage must be taking care of everything C need, including all segment registers and a valid ESP.

P.S. I tried adding magic breakpoint before calling printf function, but that damn space was already there...

Put your magic breakpoint just before leaving stage2, then go figure where it actually ends up, you'll probably be surprised

1. The compiler is all good, if I specify -m32, it compiles the code in 32bits. And okay... I renamed main to kmain -- didn't change the thing.

2. Uhm, I've wrote ELF parser, so my bootstrap actually knows what's ELF.

3. Okay, printf.o is at the very end of ld argument's list, but it didn't solve the problem.

4. That's what I'm trying to do...

[Combuster]

With that shortlist of features I'm guessing your problem is not on my list of things I'd have seen from a <10 post forum member before. And considering forum history and my own post count, that chance is really small.

Since the obvious bugs are out of the way, are you comfortable with zipping the whole thing up so I can build it locally and see how it really behaves? I can keep guessing and asking for bits but the actual bug might be practically everywhere.

[benjii]

With that shortlist of features I'm guessing your problem is not on my list of things I'd have seen from a <10 post forum member before.

Since the obvious bugs are out of the way, are you comfortable with zipping the whole thing up so I can build it locally and see how it really behaves?

If you have a bitbucket account, I could give you access to my private repo, if that's okay for you.

[Combuster]

I just found an unaligned stack, and much worse, it's stuck in reserved memory:

Code: Select all

    mov ax, 0x9000
    mov ss, ax
    mov sp, 0xFFFF

P.S. there's no buildscript in that repository of yours.

[benjii]

Uhm, actually I was too lazy to write a makefile, so I haven't done that, yet... About unaligned stack... I've aligned it, but I'm not sure what do you mean by "it's stuck on reserved memory"?

[Combuster]

What address is that stack pointing to?

[benjii]

What address is that stack pointing to?

Ah, okay, I've left SS at 0x9000, but I've changed SP to 0xFC00, so now my stack is under EBDA and is using conventional memory. That was a nice catch tho, but that unfortunately didn't fix the problem :-/.

[Combuster]

If you read that article properly, you'll see that 0x9FC00 isn't going to be a stable fix.

I'll go check if there's a buildscript when I get out of work and test the thing for myself. If not, I'll have to expire my offer because the rest of the week is going to be epically busy.

[benjii]

If you read that article properly, you'll see that 0x9FC00 isn't going to be a stable fix.

I'll go check if there's a buildscript when I get out of work and test the thing for myself. If not, I'll have to expire my offer because the rest of the week is going to be epically busy.

I'm working on it...

EDIT:

Okay, I have totally no idea what kind of magic is this... I've tried to delete an old image which I was using and redownload it from the internet (I'm using windows 98 image, LOL) and... it worked just fine! I have no space anymore at the beginning. I have no idea what the problem was, but I think it's fixed now... Anyway, I've pushed Makefile (I know, it's really ugly, because I've never learned how to write a nice Makefile) to my repo, so you can try it by yourself and tell me if that works fine for you.

I guess it's the right time to create my own image and start using it, maybe I wont come up with such a stupid and stragne bugs ^.^