Can somebody tell me if this ASM is ok ?

[Luca91]

Good evening Mike!
Still many thanks for the help
So:

- No error or warning during compilation
- Since today I'm using bochs
- Here is my budilding script (full/written by me):

Code: Select all

#!/bin/sh

build=Build
compiler=i586-elf-gcc
linker=i586-elf-ld
opt="-Wall -O -fstrength-reduce -fomit-frame-pointer -nostdinc -fno-builtin -I./Include -c -fno-strict-aliasing -fno-common -fno-stack-protector"
isodir=A_isodir
isoname=OS.iso

echo "Setting Path..."
echo "==========="
export PATH="/opt/cross/bin:$PATH"

echo "Removing Old Files..."
echo "==========="
rm -r ./Build/*
rm kernel.bin
rm $isoname
rm ./A_isodir/boot/kernel.bin

echo "Building..."
echo "==========="
# Build C files

$compiler $opt -o $build/main.o ./Kernel/main.c 
$compiler $opt -o $build/string.o ./Lib/string.c 
$compiler $opt -o $build/stdio.o ./Lib/stdio.c 
$compiler $opt -o $build/DebugDisplay.o ./Kernel/DebugDisplay.c
$compiler $opt -o $build/stdint.o ./Include/stdint.c 
$compiler $opt -o $build/Hal.o ./Hal/Hal.c
$compiler $opt -o $build/cpu.o ./Hal/cpu.c
$compiler $opt -o $build/gdt.o ./Hal/gdt.c
$compiler $opt -o $build/idt.o ./Hal/idt.c
$compiler $opt -o $build/pic.o ./Hal/pic.c
$compiler $opt -o $build/pit.o ./Hal/pit.c
$compiler $opt -o $build/exception.o ./Kernel/exception.c
$compiler $opt -o $build/panic.o ./Kernel/panic.c


# Build ASM files
nasm -f elf ./Kernel/bootstrap.asm -o $build/bootstrap.o
nasm -f elf ./Hal/i86_pit_irq.asm -o $build/i86_pit_irq.o

# Link 
$linker -T linker.ld $build/*.o


# Copy the kernel to iso building dir and create our ISO file
cp kernel.bin $isodir/boot
grub-mkrescue -o $isoname $isodir

# Launch our OS on qemu or bochs
#qemu-system-i386 -cdrom $isoname
bochs

- Here is the asm file I'm using:

Code: Select all

global i86_pit_irq
align 4

extern   i86_pit_irq_c

i86_pit_irq:
    pusha
    call      i86_pit_irq_c
    popa
    iret

- C associated function:

Code: Select all

void i86_pit_irq_c(void){
	
	_pit_ticks++;
	interruptdone(0);
}

- Pit initializer C function

Code: Select all

void i86_pit_initialize(){

	setvect(32,i86_pit_irq);
	_pit_isinit = 1;

}

- BOCHS GIVE ME THIS ERROR:

Code: Select all

00017845491i[BIOS ] Booting from 07c0:0000
00025688379i[PIT81] Changing GATE 2 to: 0
00025688390i[PIT81] Changing GATE 2 to: 1
00025908095i[PIT81] Changing GATE 2 to: 0
00083333320e[CPU0 ] check_cs(0x0010): not a valid code segment !

Sorry for the so long post, but I'm tring to give as much informations as I can so you can try to help me.
In case, I can upload the full source on github

EDIT: oh I forgot to say that I've to remove those underscore from asm because I can't compile the source with them !
EDIT2: Oh, also bochs instead of giving me default handler error, it give me kernel panic stop 13 (general protection fault)

[jnc100]

Code: Select all

00083333320e[CPU0 ] check_cs(0x0010): not a valid code segment !

During an interrupt there are only two places where CS is changed: 1) when loading the new CS fron the particular IDT entry and 2) when performing an IRET (unless you explicitly change it yourself of course). I would look for errors in these two. Particularly, ensure that the segment selector in your IDT is appropriate and that the stack is in a coherent state prior to iret.

Both of these can be confirmed with the bochs debugger. You need to set a breakpoint at the appropriate points and use 'info idt' to examine the idt and 'print-stack' to print the stack.

Regards,
John.

[neon]

Hello,

The labels in the ASM should be the C symbolic names of their respective functions in order for proper linking. I am intrigued how it can link without error without those underscores (assuming standard C name mangling.)

Unfortunately I cannot see if the current error is in the provided code. check_cs(0x0010) tells me that CS=DS which should never happen unless there is a stack problem or CS gets improperly loaded by the CPU due to improper system setup.

It might be helpful to post what you currently have and we can take a closer look at the IDT setup and initialization and make sure everything looks alright. I am not entirely convinced the error is in the provided code (absent of first note above.)

Oh, and Good evening. Hopefully we will get this one sorted out soon.

[Luca91]

Okay, I've just sent you the source in pm. I'll upload the full source on github when this interrupt problem will be fixed.

uhm, also is possible that I've to add something to esp even if I used asm handler ? (James Molloy use to add 8 to esp in his tutorial, and he wrote interrupt handlers in asm)

EDIT: why codesel is 0x8 ? (is this because 0x8 is the exec code seg ?? I was able to undestood this some days ago, but now I forgot it)

EDIT2: Yep, it is the code selector in GDT

[neon]

Am looking over it. You shouldn't need to directly modify esp. James articles appears to push additional data to the calling function (these are operands to that calling function) which would require cleanup. Your current code does not pass operands and so does not.

The code selector does not have to be 0x8. The only requirement as per the CPU manual is that entry 0 is always the null descriptor. We just selected entry 1 in the GDT as a "kernel mode 32 bit read-only executable" selector and entry 2 as "kernel mode read/write data" segment.

[Luca91]

I'm still trying to figure this out... mmm ... It looks like that the cause is the iret......
Neon, any news from your side ? Still many thanks

[neon]

Hello,

Unfortunately not yet. We were running the provided image file in the debugger and have found that the return CS for the interrupt call on the stack was indeed 0x10 which would cause the fault due to it being an invalid code segment. (This would cause it to crash on IRET.) As this was the return CS, we concluded that this value was erroneously set prior to the interrupt call which was triggered within some loop (can't give a function name since we don't have a linker map. If you would like to provide one however we can provide more information on our end.)

We should mention however that the IDT and GDT are both indeed correct and IDT[32] points to the correct assembly routine that which correctly calls your C function. This means the cause of the error is elsewhere and that everything was setup correctly here. If interested, the IDT[32].selector = 8 which is valid and would explain why the error only occurs on IRET.

We won't be able to continue the debugging session possibly until tomorrow. Please note that we are debugging the provided disk image rather then rebuilding the source thus no modifications have been made.

[Luca91]

Hello,

Unfortunately not yet. We were running the provided image file in the debugger and have found that the return CS for the interrupt call on the stack was indeed 0x10 which would cause the fault due to it being an invalid code segment. (This would cause it to crash on IRET.) As this was the return CS, we concluded that this value was erroneously set prior to the interrupt call which was triggered within some loop (can't give a function name since we don't have a linker map. If you would like to provide one however we can provide more information on our end.)

We should mention however that the IDT and GDT are both indeed correct and IDT[32] points to the correct assembly routine that which correctly calls your C function. This means the cause of the error is elsewhere and that everything was setup correctly here.

We won't be able to continue the debugging session possibly until tomorrow. Please note that we are debugging the provided disk image rather then rebuilding the source thus no modifications have been made.

Thanks mike! Just one thing: I realized that in the asm file the last istruction is IRETD in the source that I've sent to you! Maybe you should change it to IRET.. ok ?

[neon]

Hello,

Unfortunately, we can't modify the source and rebuild it due to a lack of compatible tool chain on our end. (Perhaps when the build system finally gets GCC support.) Its one of the reasons we encouraged providing the source for others on this forum as well that might have compatible build systems that might provide further help.

IRET is just expanded to either IRETW (if bits 16) or IRETD (if bits 32). If built in 32 bit mode, it should just expand to IRETD. Both forms pop CS, (E)IP, and (E)flags - only the amount of bytes popped are different. Thus changing it to IRET shouldn't make any difference. If it does then we may have found the problem.

[Luca91]

Thus changing it to IRET shouldn't make any difference. If it does then we may have found the problem.

Sadly it doesn't make any difference :/

[Luca91]

Good evening,
In the past 48h me and one of my tutors have spent a lot of hours debugging with bochs. I've also setup bochs to use the 0xE9 hack in order to print debug messages,
I can confirm that the interrupt is working, and that the C function is successfully called.
The system crash when IRET is executed.

Any news from your side Mike ?

Special thanks.


EDIT: NEON THIS IS IMPORTANT: can this problem be caused due to the fact that I'm using i586-elf-gcc (the version found on the wiki x86_64) to compile ??

[neon]

Hello,

Apologies for the latness of this reply; we were not able to look into it until about two hours ago. Most of our time debugging was locating the entry point through stack back tracing on the image file. In doing so, we get this:

Code: Select all

00083278640i[CPU0 ] | RAX=000000002badb002  RBX=0000000000010000
00083278640i[CPU0 ] | RCX=0000000000000000  RDX=0000000000000000
00083278640i[CPU0 ] | RSP=000000000007fef8  RBP=0000000000000000
00083278640i[CPU0 ] | RSI=0000000000000000  RDI=0000000000000000
00083278640i[CPU0 ] |  R8=0000000000000000   R9=0000000000000000
00083278640i[CPU0 ] | R10=0000000000000000  R11=0000000000000000
00083278640i[CPU0 ] | R12=0000000000000000  R13=0000000000000000
00083278640i[CPU0 ] | R14=0000000000000000  R15=0000000000000000
00083278640i[CPU0 ] | IOPL=0 ID vip vif ac vm rf nt of df if tf sf ZF af PF cf
00083278640i[CPU0 ] | SEG selector     base    limit G D
00083278640i[CPU0 ] | SEG sltr(index|ti|rpl)     base    limit G D
00083278640i[CPU0 ] |  CS:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00083278640i[CPU0 ] |  DS:0018( 0003| 0|  0) 00000000 ffffffff 1 1
00083278640i[CPU0 ] |  SS:0018( 0003| 0|  0) 00000000 ffffffff 1 1
00083278640i[CPU0 ] |  ES:0018( 0003| 0|  0) 00000000 ffffffff 1 1
00083278640i[CPU0 ] |  FS:0018( 0003| 0|  0) 00000000 ffffffff 1 1
00083278640i[CPU0 ] |  GS:0018( 0003| 0|  0) 00000000 ffffffff 1 1
00083278640i[CPU0 ] |  MSR_FS_BASE:0000000000000000
00083278640i[CPU0 ] |  MSR_GS_BASE:0000000000000000
00083278640i[CPU0 ] | RIP=0000000000100898 (0000000000100898)
00083278640i[CPU0 ] | CR0=0x60000011 CR2=0x0000000000000000
00083278640i[CPU0 ] | CR3=0x00000000 CR4=0x00000000

Although you install a new GDT using LGDT, the selector registers are never changed. That is, you need something like this after reloading a different GDT,

Code: Select all

   mov ax, 0x10
   mov ds, ax
   mov es, ax
   mov ss, ax
   mov fs, ax
   mov gs, ax
   jmp 8:flush_cpu
flush_cpu:

This step is important as all modern IA32 CPU's use a segment descriptor cache in order to avoid fetching GDT information from the in-memory table.

Please let us know if it works or causes more problems. We suspect it would also resolve the IRET error on interrupt return.

i586-elf-gcc is fine. IIRC its the version we used a long time ago.

[Luca91]

IT WORKS !!!
Thank you mikeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

I've to admit, some days ago while re-reading one of your boot-stage tutorial I was thinking about that far jump, but since this is not explained in the kernel series I totally ignored this !

Well mate, you really rescued me

If I can suggest, please add that note to your tutorials, this can save a lot of headache to future os developers

Stil many many thanks ... Tomorrow I'll upload the kernel on github and I'll start to implement memory

[neon]

Great to hear that it works! Sorry it took so long, just been so busy lately.

We plan an update to the articles soon so will be sure to add additional details on the segment descriptor caches. Thank you for the suggestion and the best of luck with your project!