Page 2 of 3
Re: cross-compiler question
Posted: Sat Jun 05, 2010 11:26 am
by Gman
I did build binutils, but I think the problem is that my linker script is placing memory in a format that isn't an elf, so objdump is freaking out.
When I tried the --target=binary,
It replies with
kernel.bin file format binary
objdumpL Can't dissaemble for archetecture UNKNOWN!
Re: cross-compiler question
Posted: Sat Jun 05, 2010 11:45 am
by gerryg400
You need to supply --architecture=i386 as well.
Re: cross-compiler question
Posted: Sat Jun 05, 2010 12:33 pm
by Gman
Ok, what am I supposed to do with the output, i can get the assembly, but wven with intel syntax it is very hard to understand. I am only using the disassemble option, as that is the only one that seems like it would have an effect on a binary file.
Re: cross-compiler question
Posted: Sat Jun 05, 2010 7:48 pm
by gerryg400
Remember how, earlier in the thread, I suggested you target ELF. This is one of the reasons. You would have all your symbols there and it's very easy to see what's happening.
Never mind, you need to find the function call to your print function and check that the address being passed to it is the address of the string.
Could you perhaps build an ELF version just do you can disassemble it to see what's happening ?
Re: cross-compiler question
Posted: Sat Jun 05, 2010 10:31 pm
by Gman
Ok, I think it is an elf now, and from what I can tell the address is correct. The address that is being passed is 0x100342, my text section starts at 0x1000, and my text is at 0x1342.
I tried again with a binary file, and I think I found my problem. The address loaded is 0x342, which, when I look at the memory in that area is 0x0340 53 FF 00 F0 53 FF 00.
when rodata is in the text section the address loaded is 0x342, as stated above, but when rodata is loaded in data, the address is 0x344, which would explain why S is the data being printed.
All I had to do to fix it was add . = 0x100000; above .text
Now everything is working
Thank you so much for all of your help.
Re: cross-compiler question
Posted: Sat Jun 05, 2010 10:54 pm
by gerryg400
Cool, what's next?
Re: cross-compiler question
Posted: Sat Jun 05, 2010 11:32 pm
by Gman
right now I'm just happy, and shocked, I have a bootloader that can successfully load a kernel.
Re: cross-compiler question
Posted: Sun Jun 06, 2010 4:58 pm
by Gman
Ok, I have a new problem that I believe is related to my linker script, so I'll post it here. I have loaded my IDT, but the address are relative to the start of my kernel, not 0x100000 like it says in my linker script. When I check the address's of the functions in the IDT, they are numbers like 0x72f ,when they should be something like 0x10072f, I think. I thought adding . = 0x100000 would have solved that problem.
Also, I have tried to manually change the addresses of the entries once bochs is running, and when I change the high part of the offset it restarts, but when I change the lower part of the offset everything is fine.
Re: cross-compiler question
Posted: Sun Jun 06, 2010 6:27 pm
by gerryg400
The linker script should be correct now that you've added the . = 0x100000
So are you sure that the code that fills in the idt is correct ? The upper and lower 16 bits of addresses in the idt are not contiguous in memory.
Re: cross-compiler question
Posted: Sun Jun 06, 2010 10:08 pm
by Gman
Here is my code for it, I don't see anything wrong:
IDT Struct:
Code: Select all
typedef struct IDT_struct{
u16 offsetLow;
u16 segSelector;
u8 reserved;
u8 attributes;
u16 offsetHigh;
}__attribute__((packed)) IDT_t;
installIDT:
Code: Select all
void installIDT(){
u16 i = 0;
for(;i<256;i++){
IDTSetGate(i,0x0,0x0,GATE32 | RING0);
}
IDTSetGate(0,0x100000+(u32)isr0,0x08,0x8e);
IDTSetGate(1,(u32)isr1,0x08,0x8e);
IDTSetGate(2,(u32)isr2,0x08,0x8e);
IDTSetGate(3,(u32)isr3,0x08,0x8e);
IDTSetGate(4,(u32)isr4,0x08,0x8e);
IDTSetGate(5,(u32)isr5,0x08,0x8e);
IDTSetGate(6,(u32)isr6,0x08,0x8e);
IDTSetGate(7,(u32)isr7,0x08,0x8e);
IDTSetGate(8,(u32)isr8,0x08,0x8e);
IDTSetGate(9,(u32)isr9,0x08,0x8e);
IDTSetGate(10,(u32)isr10,0x08,0x8e);
IDTSetGate(11,(u32)isr11,0x08,0x8e);
IDTSetGate(12,(u32)isr12,0x08,0x8e);
IDTSetGate(13,(u32)isr13,0x08,0x8e);
IDTSetGate(14,(u32)isr14,0x08,0x8e);
IDTSetGate(15,(u32)isr15,0x08,0x8e);
IDTSetGate(16,(u32)isr16,0x08,0x8e);
IDTSetGate(17,(u32)isr17,0x08,0x8e);
IDTSetGate(18,(u32)isr18,0x08,0x8e);
IDTSetGate(18,(u32)isr18,0x08,0x8e);
IDT_Desc_t IDT_Descriptor;
IDT_Descriptor.size = (sizeof(IDT_Entries[0])*256)-1;
IDT_Descriptor.offset = (u32)IDT_Entries;
SetIDT(&IDT_Descriptor);
}
SetIDT:
Code: Select all
SetIDT:
push ebp
mov ebp,esp
mov ebx,[ebp + 8]
lidt [ebx]
pop ebp
ret
When I dumped my code with objdump I found that the correct address is being loaded into my function, but the wrong address is put into memory.
Also, while in the debugger, if I change the value of the last 16 bits, from the value of 0x0000 to 0x0010, which would make my address become 0x0010079f, and cause a divide-by-zero exception, the code triple faults.
Re: cross-compiler question
Posted: Sun Jun 06, 2010 10:21 pm
by gerryg400
Can you post the code for "IDTSetGate" ?
Do you know yet why you have to add 0x100000 to get the function pointer right? You need to fix that problem first. Little things like this have all sorts of ripple effects.
You have a working kprintf function ? Try printing the address of your isr0 routine. If you haven't got kprintf yet, make one. I've worn out 3 or 4 kprintfs already while making my kernel.
Re: cross-compiler question
Posted: Mon Jun 07, 2010 12:03 am
by Gman
forget about the +0x100000, that isn't suposed to be there, it should be:
Code: Select all
void installIDT(){
u16 i = 0;
for(;i<256;i++){
IDTSetGate(i,0x0,0x0,GATE32 | RING0);
}
IDTSetGate(0,(u32)isr0,0x08,0x8e);
IDTSetGate(1,(u32)isr1,0x08,0x8e);
IDTSetGate(2,(u32)isr2,0x08,0x8e);
IDTSetGate(3,(u32)isr3,0x08,0x8e);
IDTSetGate(4,(u32)isr4,0x08,0x8e);
IDTSetGate(5,(u32)isr5,0x08,0x8e);
IDTSetGate(6,(u32)isr6,0x08,0x8e);
IDTSetGate(7,(u32)isr7,0x08,0x8e);
IDTSetGate(8,(u32)isr8,0x08,0x8e);
IDTSetGate(9,(u32)isr9,0x08,0x8e);
IDTSetGate(10,(u32)isr10,0x08,0x8e);
IDTSetGate(11,(u32)isr11,0x08,0x8e);
IDTSetGate(12,(u32)isr12,0x08,0x8e);
IDTSetGate(13,(u32)isr13,0x08,0x8e);
IDTSetGate(14,(u32)isr14,0x08,0x8e);
IDTSetGate(15,(u32)isr15,0x08,0x8e);
IDTSetGate(16,(u32)isr16,0x08,0x8e);
IDTSetGate(17,(u32)isr17,0x08,0x8e);
IDTSetGate(18,(u32)isr18,0x08,0x8e);
IDTSetGate(18,(u32)isr18,0x08,0x8e);
IDT_Desc_t IDT_Descriptor;
IDT_Descriptor.size = (sizeof(IDT_Entries[0])*256)-1;
IDT_Descriptor.offset = (u32)IDT_Entries;
SetIDT(&IDT_Descriptor);
}
IDTSetGate:
Code: Select all
void IDTSetGate(u8 i,u32 offset, u16 selector, u8 attributes){
IDT_Entries[i].offsetLow = offset & 0xffff;
IDT_Entries[i].segSelector = selector;
IDT_Entries[i].reserved = 0;
IDT_Entries[i].attributes = attributes;
IDT_Entries[i].offsetHigh = (offset & 0x0000ffff) << 16;
}
as I stated before, the correct offset is being passed to the function.
Re: cross-compiler question
Posted: Mon Jun 07, 2010 12:05 am
by gerryg400
Code: Select all
IDT_Entries[i].offsetHigh = (offset & 0x0000ffff) << 16;
Shouldn't that be ?
Code: Select all
IDT_Entries[i].offsetHigh = (offset >> 16) & 0x0000ffff;
Re: cross-compiler question
Posted: Mon Jun 07, 2010 4:43 pm
by Gman
gerryg400 wrote:Code: Select all
IDT_Entries[i].offsetHigh = (offset & 0x0000ffff) << 16;
Shouldn't that be ?
Code: Select all
IDT_Entries[i].offsetHigh = (offset >> 16) & 0x0000ffff;
I fixed the code, the correct version was:
Code: Select all
IDT_Entries[i].offsetHigh = (offset & 0xffff0000) >> 16;
It still restarts though.
Here is the entry in the IDT for interrupt 0, which I am triggering with a divide-by-zero error:
Code: Select all
0x00102940 9f 07 08 00 00 8E 10 00
where 0x10079f is the location of my interrupt.
Re: cross-compiler question
Posted: Mon Jun 07, 2010 5:37 pm
by gerryg400
The IDT entry looks correct. Check these.
1. Are you doing ligt correctly ? Have a peek at IDT_Descriptor and make sure it is packed correctly ? Make sure the 6 bytes are contiguous.
2. Is the base of the data segment 0 ? The IDT_Descriptor needs a linear address, not seg relative.