Loading IDT

[OSMAN]

Hello.

I took this from the past because now I have the same problem that "tm-" had.

TELL ME please, what do I have do to fix the syntax of this in IDT:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
dw isr1 & 0xFFFF
dw 0x08
dw 0x8E00
dw (isr1 >> 16) & 0xFFFF
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(can you make these calculations in data section?)

"Syntax error
Syntax error"
is the output of bash terminal.

I tried to put the brackets to specify the pointer, but no.
Please help. My ISR is depending on this, and I'm not an asm guru
(, not yet at least :)

[Brendan]

Hi,

TELL ME please, what do I have do to fix the syntax of this in IDT:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
dw isr1 & 0xFFFF
dw 0x08
dw 0x8E00
dw (isr1 >> 16) & 0xFFFF
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(can you make these calculations in data section?)

"Syntax error
Syntax error"
is the output of bash terminal.

For which assembler?

If you're using NASM, then see:
NASM documentation

It's the same problem with different code. Basically you'd need to do something like:

Code: Select all

%define ORIGIN 0x1234567

    org ORIGIN

CODE_SECTION_START:


    section .data
    dw (isr1 -CODE_SECTION_START + ORIGIN) & 0xFFFF
    dw 0x08
    dw 0x8E00
    dw ((isr1 -CODE_SECTION_START + ORIGIN) >> 16 & 0xFFFF

Although the "Syntax error" doesn't look like one of NASM's error messages...


Cheers,

Brendan

[OSMAN]

Hi.

I'm using Nasm.

Is there any other way, I mean just to fix the syntax of exact this:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
dw isr1 & 0xFFFF
dw 0x08
dw 0x8E00
dw (isr1 >> 16) & 0xFFFF
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

I don't think fixing the syntax should add that many things:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
%define ORIGIN 0x1234567 ; <- would this be the start of the file?

org ORIGIN

CODE_SECTION_START:


section .data
dw (isr1 -CODE_SECTION_START + ORIGIN) & 0xFFFF
dw 0x08
dw 0x8E00
dw ((isr1 -CODE_SECTION_START + ORIGIN) >> 16 & 0xFFFF
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(Please keep it simple but working.)

[bubach]

This is how my old NASM source looks ( using fasm and diffrent code now, so i don't remember much except that this worked for me):

kernel.asm

Code: Select all

     [BITS 32]
     [ORG 0x100000]

     %define orgaddress 0x100000    ; Used by idt.
.........

idt.inc

Code: Select all

; Interrupt Description Table.
;------------------------------
idt_start:

     ; 0. Interrupt 0x00.
     ;---------------------
     dw isr00
     dw 0x08
     db 0
     db 0x8E
     dw (orgaddress>>16)

     ; 1. Interrupt 0x01.
     ;---------------------
     dw isr01
     dw 0x08
     db 0
     db 0x8E
     dw (orgaddress>>16)
.......

[OSMAN]

But my nasm doesn't know what's ORG; it says "instruction expected" to line "ORG 0x1000000" and some another error to "[ORG 0x1000000]"!
How can this be so difficult to find out!

(please answer; my only hope)

[Pype.Clicker]

But my nasm doesn't know what's ORG; it says "instruction expected" to line "ORG 0x1000000" and some another error to "[ORG 0x1000000]"!
How can this be so difficult to find out!

(please answer; my only hope)

That's a strange nasm you get, if you ask me. According to the nasm manual aswell as the nasm code i have here, "org 0x1234" is perfectly valid and it should work ... i'm unsure about an "org XXXX" where XXXX>64K in "16 bits" mode, though ...

[OSMAN]

Now I don't like this at all! How can my nasm differ from everybody elses'?!

So, I don't want to stop my OS here beacause of that "org".

Is there any other way than using the ORG?

[Brendan]

Hi,

Now I don't like this at all! How can my nasm differ from everybody elses'?!

It could be an extremely old version or a completely different executable that's been called "nasm" even though it's not (this is easy to check with "nasm -r").

but

I think it's much more likely that the difference is the command line options you're using compared to most other people .

Are you generating flat binary output (the "-f bin" option, which is usually the default output format) or are you generating object files (elf, a.out or something)?

For flat binary files, NASM controls everything and ORG tells it the address that the binary file should use.

For object files, the address that the resulting binary file should use is determined by the linker or a linker script and not NASM. In this case (AFAIK) the ORG instruction is an error and shouldn't be present.

If this is the case, then I'm not sure what you'd need to do to get around it.

For example, you may need to define a global symbol in the linker script called "CODE_SECTION_START" (or any other name you feel like), and then use something like:

Code: Select all

    section .text
    dw (isr1 - $$ + CODE_SECTION_START) & 0xFFFF
    dw 0x08
    dw 0x8E00
    dw ( (isr1 - $$ + CODE_SECTION_START) >> 16) & 0xFFFF

Notice that this is in the ".text" section not the ".data" section - the special symbol $$ means the address for the start of the current section, so the current section must match the section the label "isr" was created in.

There's probably more elegant ways to do this (I don't use linkers though, so I'm not sure)...


Cheers,

Brendan

[Pype.Clicker]

Now I don't like this at all! How can my nasm differ from everybody elses'?!

Well, so maybe you could like to give us a proper test case with "the smallest file you can create that reproduce the error", full information about your version of nasm, your environment, the exact command you issued to NASM and the exact error message it gives you.

That way it will be less "how difficult it can be to find out"

[OSMAN]

Okay,
here's a line in my makefile:
NASM   =nasm -f elf

(I think elf has something to do with the problem)

i'm using Fedora Core 4 and the nasm which came with it.

Can you now help me?

[Pype.Clicker]

that may better explain your problem: depending on the binary format you used, some directive are/aren't available to NASM. The ORG directive (telling at which offset the data should start) makes little sense when creating an ELF file (that is meant to be linked with something else, presumably).

Section 6 of the NASM manual ("info nasm" should give it to you) will show you what's special with each one.

So the "org xxxx" will not work with ELF. If that don't suits you, complain to Tolkien ;D

Other things you can do include:
- write your functions table as "dd myISRxxx" and then use a runtime code to read that table, split high/low ids and fill them in the IDT
- use the "symbol - $tart of $ection" trick:

Code: Select all

stuff dw 0xdead
      dw (here + PHYS - $$) >> 16
      dw 0xbeef
      dw (here + PHYS - $$) & 0xFFFF

with appropriate linker script, you can enforce the '.text' section to start at 1MB, for instance, in which case you just %define PHYS 0x100000 ...

[OSMAN]

Let's continue the discussion about this problem.

;;;;;IN DATA SECTION;;;;;;;
dw isr1 & 0xFFFF
dw 0x08
dw 0x8E00
dw (isr1 >> 16) & 0xFFFF
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

My error is something like "this & and this >> operator may only be applied to scalar values!"

I will build my IDT as run-time afterwards, but I want to understand why is this so ,even you keep telling me it should work!
(Hey, is this elf's work again?)


When I want to do it as run-time, will I have to put ISR-pointer to i.e. EAX
and read it to IDT from EAL and EAH to get 16 bit pointers?

[Brendan]

Hi,

My error is something like "this & and this >> operator may only be applied to scalar values!"

Did you try this (hopefully the solution):

For example, you may need to define a global symbol in the linker script called "CODE_SECTION_START" (or any other name you feel like), and then use something like:

Code: Select all

    section .text
    dw (isr1 - $$ + CODE_SECTION_START) & 0xFFFF
    dw 0x08
    dw 0x8E00
    dw ( (isr1 - $$ + CODE_SECTION_START) >> 16) & 0xFFFF

Notice that this is in the ".text" section not the ".data" section - the special symbol $$ means the address for the start of the current section, so the current section must match the section the label "isr" was created in.

..or look at this link (the reason for the problem):

http://nasm.sourceforge.net/doc/html/na ... ion-10.1.4

When I want to do it as run-time, will I have to put ISR-pointer to i.e. EAX and read it to IDT from EAL and EAH to get 16 bit pointers?

There's no such thing as "EAH", and "EAL" is called "AX". To create IDT entries at run time, you'd do something like:

Code: Select all

;Make an IDT entry
;_______________________________________________________________________________
;
;Input
; eax   Offset for interrupt handler
; bl   Interrupt type (0x8F = trap gate, 0x8E = interrupt gate)
; edx   Address of IDT entry
;_______________________________________________________________________________

makeIDTentry:
   push eax
   mov [edx],ax
   mov word [edx+2],SELECTORkernelCode
   shr eax,16
   mov byte [edx+4],0x00
   mov byte [edx+5],bl
   mov [edx+6],ax
   pop eax
   ret

Cheers,

Brendan

[OSMAN]

Hey.

Could you comment that makeIDTentry-routine, 'cause i didn't understand it very well? Would it be okay to be somekind of that I push the arguments to the stack and call the routine which pops and operates with them?
(As I mentioned I'm not asm gugu, so please comment the code.)

[Pype.Clicker]

sorry if that sounds rude, but if you don't grasp the meaning of _that_, then you should seriously learn more assembly before you go on ...

What it does is
[tt]
;; INPUT
;; eax == your_handler_address
;; edx == IDT_BASE + 8*INTERRUPT ENTRY


;; OUTPUT ( data structure pointed by EDX)
;; +-------------------
;;+0 | handler_address
;; | bits 0-15
;;+2 | SELECTOR
;; | (kernel code)
;;+4 | 0
;;+5 | gate type
;;+6 | handler_address
;; | bits 16-31
;; NO REGISTER CHANGED.
[/tt]

The only things that worth being mentionned is that
1. eax is saved then restored so that the function doesn't modify it
2. using "shl eax, 16" shifts the bits 16-31 of your handler address into bits 0-15 of eax so that you can just use "ax" to move them in the structure
3. assume the knowledge of IDT entries from Intel Manuals.