Getting application base address in interrupt handler

[Revelation]

I'm currently building interrupts for user application to call.

This code for example should print a message:

Code: Select all

[bits 32]
	call PrintMessage
	cli
	hlt

PrintMessage:
	mov eax, 0
        mov ecx, mes
        mov edx, 11  ; size
        int 0x30
	ret

mes db "ROFLMAO!!!!"

But as you can see ecx now contains only the offset of mes in the app. To print the message correctly I must know the base address. How can I find that from within my interrupt handler?

[Craze Frog]

At the start of you app, put ORG WhereTheAppIsLoaded, and then make sure you load the app at that location in memory. Then the reference to mem should be correct.

[Love4Boobies]

If you want to use PIC (Position Independent Code), you might want to pass applications the base address for code and data segments in say, some register at startup. Things can get complicated, but just so you have an idea...

[Revelation]

At the start of you app, put ORG WhereTheAppIsLoaded, and then make sure you load the app at that location in memory. Then the reference to mem should be correct.

I am talking about a dynamic system, so this is not an option.

If you want to use PIC (Position Independent Code), you might want to pass applications the base address for code and data segments in say, some register at startup. Things can get complicated, but just so you have an idea...

I am in protected mode, so my code segment is 0x08 and not a real mode segment. How does Linux or Windows do this? Do they make a new GDT entry?

[Love4Boobies]

I am in protected mode, so my code segment is 0x08 and not a real mode segment. How does Linux or Windows do this? Do they make a new GDT entry?

I'm not really sure how you handle things. For instance, are you using a segmented memory model? Both Windows and Linux use the flat memory model, meaning that for all aplications, memory for both code and data starts at offset 0. When compared to the segmented memory model, yes, there is a penalty related to TLB flushes but the page technique makes the job SO MUCH easier for compilers as they can optimize a lot better and won't have to use PIC for everything. Besides creating a more friendly environment (it looks to the application as though it has the whole memory to itself), using virtual memory is easier this way as there won't be any problems if anyone needs to allocate more memory than its small 'segmented-memory segment'. So it's easier for the memory manager as well. The way they do this is using pages.

[Revelation]

Okay, so now it's really time to start implementing paging. Thanks!

[Craze Frog]

How does Linux or Windows do this?

Just like I told you to do it. And with paging.

But if you just want to test your text printing function, this could probably work:

Code: Select all

   PUSH $
   CALL PrintMessage
   POP  eax
   CLI
   HLT

PrintMessage:
   MOV eax, 0
   MOV ecx, dword [esp+4]
   SUB ecx, dword [esp]
   LEA ecx, [mes+ecx+10]
   MOV edx, 11
   INT $30
RET

mes DB "ROFLMAO!!!!"

[yemista]

i think you need some kind of message passing for it to work. in which cases would an interrupt need to read program data?