OSDev.org

Hi all, I am building a kernel, and need to build a simple IDT loader system.
I am coding in pure ASM. (protected mode, 32 bit)

The idea is that...

1. I load a file from the root directory defining what files need to be loaded into memory, and what IDT's correspond to which binary which is now in memory. (Not coded, but I can do this)
2. Based on the instructions in this file, modify existing entries in the IDT (on already exists thanks to aeBIOS) to point to the new file which we loaded into memory.

The idea is a system that can load an interrupt handler from a file, and register it with an IDT, to handle that interrupt.
How would you do Step 2??? Im talking writing to the IDT, with the correct infromation.

Thankyou very much in advance.

-Hyperzap

I didn't knew modifying the idt was that difficult?

modify existing entries in the IDT (on already exists thanks to aeBIOS)

You usually can't use the BIOS and the real-mode IDT under protected mode. Setting up your own IDT is a one of thing you'd do after enter to protected mode.
If you're unsure how to manipulate IDT, you should take a look on babystep examples on the wiki;
and it sounds too early to actually implement fancy things (ie. loadable module) before you have an IDT work.

Furthermore, it's not recommended to have loadable module to directly be an INT handler,
since one module could be interested on multiple INT, or multiple drivers may share the same INT.

your kernel could have managed it and allow chains, etc.

Hi,

bluemoon wrote:

modify existing entries in the IDT (on already exists thanks to aeBIOS)

You usually can't use the BIOS and the real-mode IDT under protected mode.

aeBIOS is a project that tries to make all the broken ugly mess from the 1970's "real mode BIOS" available in protected mode, so it's easy to make broken and ugly protected mode software (rather than broken and ugly real mode software)...


Cheers,

Brendan

Well, I actually don't know such project :p Thanks for noticing.

bluemoon wrote:

modify existing entries in the IDT (on already exists thanks to aeBIOS)

You usually can't use the BIOS and the real-mode IDT under protected mode. Setting up your own IDT is a one of thing you'd do after enter to protected mode.
If you're unsure how to manipulate IDT, you should take a look on babystep examples on the wiki;
and it sounds too early to actually implement fancy things (ie. loadable module) before you have an IDT work.

Furthermore, it's not recommended to have loadable module to directly be an INT handler,
since one module could be interested on multiple INT, or multiple drivers may share the same INT.

your kernel could have managed it and allow chains, etc.

Sorry everyone for the confusion. My expression is terrible.

I looked at the info and I now have a grasp of manipulating the IDT. This issue now is this:

When I write code in assembly, I normally have to specify where it will be loaded (using 'org').
But with a dynamic loader, it could go in many locations.
So how do you deal with this???
Thankyou in advance.

Hi,

hyperzap wrote:When I write code in assembly, I normally have to specify where it will be loaded (using 'org').
But with a dynamic loader, it could go in many locations.
So how do you deal with this???

In order of my personal preference, the options are:

1. Use paging so that everything can run at its "org" and there's no problem
2. Use segmentation so that everything can run at its "org" and there's no problem
3. Write/generate position independent code (requires special support in the toolchain)
4. Keep track of offsets, etc and patch the code to set/correct offsets during loading (requires special support in the toolchain and loader)

Cheers,

Brendan

Brendan wrote:Hi,

hyperzap wrote:When I write code in assembly, I normally have to specify where it will be loaded (using 'org').
But with a dynamic loader, it could go in many locations.
So how do you deal with this???

In order of my personal preference, the options are:

1. Use paging so that everything can run at its "org" and there's no problem
2. Use segmentation so that everything can run at its "org" and there's no problem
3. Write/generate position independent code (requires special support in the toolchain)
4. Keep track of offsets, etc and patch the code to set/correct offsets during loading (requires special support in the toolchain and loader)

Cheers,

Brendan

do you have any information/links about the flat binary format? (ie what is made by the assembler for os dev)

hyperzap wrote:do you have any information/links about the flat binary format? (ie what is made by the assembler for os dev)

Flat binary format is a non-format. The contents are simply the opcodes and data specified in the assembly file, in the order in which they appear (unless you reorder them somehow.) There are no metadata whatsoever.