problem in linking the kernel

[adeelmahmood1]

i use to load my kernel into the memory at 0x0000:5000 now due to some problems i need to load
it at 1 MEG. so 5000h everything worked fine and the linker script i m using is

Code: Select all

OUTPUT_FORMAT("binary")
ENTRY(start)
SECTIONS
{
  .text  0x5000 : {
    *(.text)
  }
  .data  : {
    *(.data)
  }
  .bss  :
  {                
    *(.bss)
  }
}

so i changed this in my boot loader to load kernel at es:bx-->0x1000:1000 and changed this 0x5000 into 0x100000 in this linker
script and now on compiling i get this error
interrupts.o      relocation truncated to fit: 16 .data
the interrupts.asm is attached
thanx for ur help


[attachment deleted by admin]

[Pype.Clicker]

what is most likely to occur is that you wrote the address of the interrupt handler as a constant in your IDT descritors ... but now, it is too large to fit the small DW you reserved ...

Check out the archives, there might be a workaround using something like
(handler - $$ + TARGET) & 0xFFFF and (handler - $$ +TARGET) >>16,
but if i were you, i would just write a setup_idt function that will patch the descriptors correctly (by splitting the address of the handler from 32 bits into 2x16 bits and writing them at the right place...

[adeelmahmood1]

sorry pype i dont understand wat u r trying to tell me ..
if it is like that then why it was working fine when i use to load the kernel at 0000:5000h ..
BTW thanx for ur help :-\

[Pype.Clicker]

probably because 0x5000 fits in a word, while 0x100000 doesn't ...

[Ozguxxx]

Hi,I just want to simplify what Pype.Clicker is telling. (I hope it is alright for you Pype.Clicker ;D) I dont know if this is what is causing your problem but here it is:
Format of an interrupt gate is as:

offset 31...16 -> Highest word in memory.
some configuration word -> 3rd word.
selector (15 bits, fits all here) -> 2nd word.
offset 16...0 -> Lowest word in memory.

All makes 4 words=8 bytes of information. Trap gate is very similar to this, only configuration word is different. Anyway, since offset part is 32 bits(I dont know why they did this) it is divided into high and low words and these are put in different (unfortunately not adjacent ) positions in the descriptor. So in your code, you have to put 0x100000(=1Meg AND assuming your selector is 0 based) so you have to divide this into two words as: 0x0010 (higher word: bits from 31...16) and 0x0000 (lower word: bits from 15...0) So now you have to set highes word entry in descriptor to 0x0010 and lowest word entry to 0x0000. Thats all...

[Ozguxxx]

BTW to avoid misunderstanding, I have just showed a dramatization I mean it is obvious that your selector wont be 0 based, you have to make correct bit shiftings and etc. to calculate what exactly will be put into these high and low order word entries, I just wanted to make situation simpler so that it will be easier to tell and understand. So Pype.Clicker's advice on setup_idt function written in c will be most easy way to get around this I think.

[Pype.Clicker]

Anyway, since offset part is 32 bits(I dont know why they did this) it is divided into high and low words and these are put in different (unfortunately not adjacent ) positions in the descriptor.

They did it to be backward compatible with 286 which had protected mode (segmentation, at least), but no paging and a 16MB address space and 64K segments (so the last 2 bytes of the GDT were reserved for Future eXtentions ...

[adeelmahmood1]

hi
well ozguxx quite simplified wat pype said
but the problem is this that i can understand wat u r saying but i dont have a clue in my mind how to do that .. this is why i m attaching this the code which actually sets up the IDT .. if u could plz look at it and then tell me about this setting up the bits and making my selector 0 based.
thanx for ur help


[attachment deleted by admin]

[Pype.Clicker]

hmm ... seems we were wrong from the start assuming the problem came from your IDT (well, it is so classical that i figured out *that* could be the only problem as long as i saw your IDT.c ::) )

Well, anyway, the problem remains the same but it just hides a bit better...

Look at

Code: Select all

        mov     bx, ax
        cmp     byte [_EXC_HAS_ERROR+bx], 0
        je      .1

[ <immediate> + bx ] is a 16-bits addressing mode, and it is assembled very differently from [ <immediate> + ebx ] (among others, in order to be in a code32 section, it needs a db 67 prefix ).

Now, let's think about it: as [ bx + <imm> ] is a 8086 instruction, its offset field (the <imm> which is holding the base of the array rather than a constant index here) is limited to 16 bits.

i think if you replace your code with

Code: Select all

movzx ebx,ax
cmp [_EXC_HAS_ERROR + ebx],1

you'll solve your problem

[adeelmahmood1]

well i can definately accept that i could never have found out this problem which pype indicated. Yes pype u r right i changed the code and that error has gone .. at the moment altthough it is just compiling but on running it just resets but that i will figure out some how.
thanx alot for ur help

[Perica]

..

[Tim]

Better:

Code: Select all

dw Address >> 16  ; High word
dw Address & 0FFFFh   ; Low word

However, you can't use >> and & on expressions (such as Address) that the assembler itself can't resolve. This includes symbols that are defined in other files.

[adeelmahmood1]

ok another stupid problem
while i was loading my kernel at 0000:5000h i use to jump like this from my boot loader to kernel by
jmp CODE_SEL:0x5000
now when i m loading it at 1 MEG where should i jump
is it
jmp CODE_SEL:0x100000
or what?
thanx for ur help

[distantvoices]

it should do the job. I load gdt and jump to prot.mode prior to this jump, then I perform it.

[adeelmahmood1]

well now everything is fine but at the end the same problem came back ... when i try to setup my new GDT which is in C (i have already posted that in my multitasking thread) .. it gives me a 'running in bogus memory' bochs error..
i have no idea about this error :-\
well BTW thanx to all of u for ur help