Page 1 of 1
Good way to end a beginning process.
Posted: Thu Oct 21, 2004 2:39 pm
by stonedzealot
My OS can handle jumping a new task but it can't handle one dying. Right now, I'm essentially injecting the assembly code with a pointer and the first process I created was just CD21F4 (interrupt 33, hlt) so I made a pointer to the new page (temp) and set
When the scheduler decides to switch from the kernel to the task, I get the interrupt 33 call, it prints a message, but then refuses to halt on return. If I remove the message from the interrupt, it will just return from the interrupt and continue to execute until it crosses the page barrier and gives a page fault. If the message is retained within the interrupt, then it does some really weird **** when it hits the instruction after the hlt (which it should never do anyway). So why isn't it halting at the hlt, or how should I loop the process at the end, since I can't handle one dying yet (and won't, until I make sure that I can sustain them)?
Re:Good way to end a beginning process.
Posted: Thu Oct 21, 2004 5:13 pm
by mystran
If this is usermode task, then remember that halt cannot be used in ring3 and IIRC trying to do so results in general protection fault.
Re:Good way to end a beginning process.
Posted: Fri Oct 22, 2004 12:30 am
by Ytinasni
The HLT instruction waits for one interrupt to occur, then continues.
Re:Good way to end a beginning process.
Posted: Fri Oct 22, 2004 9:53 am
by stonedzealot
I'll be damned, I didn't know that. I should've guessed. Anyway, I've been trying to avoid the HLT instruction now by looping so I wrote this little NASM program:
Code: Select all
[BITS 32]
[ORG 0x800000] <-- That's the address we're running from.
int 33
jmp 0x800000
and it generates CD 21 E9 F9 FF FF FF which I insert like this:
Code: Select all
temp = (int *) 0x800000;
temp[0] = 0xF9E921CD;
temp[1] = 0xFFFFFF;
and when I execute it goes totally haywire (still fires the interrupt all right, but doesn't loop correctly or something). So what would a better loop strategy be? Or, at least, what am I doing wrong?
Re:Good way to end a beginning process.
Posted: Fri Oct 22, 2004 8:44 pm
by mystran
Ok, so you have a relative jump here with 32-bit offset, which makes little sense since 8 bit offset would do just as well. But other than that, it _seems_ ok.
Anyway, are you sure you return everything into such a state that the interrupt can be safely fired again? I find it quite likely that the problem is somewhere else.
Anyway, I'd try to find a way to include your assembler generated code directly into your kernel. One option is to simply put a label before and after the asm-code (maybe compile it into .data section?) then link it normally, and use the labels to find it and copy it where you want it. That way you avoid manually typing bytes.
Re:Good way to end a beginning process.
Posted: Sun Oct 24, 2004 1:12 pm
by Dreamsmith
If you meant to simply loop in place rather than call INT 33 over and over and over again, you might want to use:
...which assembles as EB FE. Add the INT instruction (CD 21) so you get *temp = 0xFEEB21CD, a lovely little 4 byte program. ;D
Re:Good way to end a beginning process.
Posted: Sun Oct 24, 2004 2:00 pm
by Candy
Dreamsmith wrote:
If you meant to simply loop in place rather than call INT 33 over and over and over again, you might want to use:
...which assembles as EB FE. Add the INT instruction (CD 21) so you get *temp = 0xFEEB21CD, a lovely little 4 byte program. ;D
If you do want to call the function again, adjust the 1-byte offset two backwards, to EB FC. Giving:
*temp = 0xFCEB21CD
for the same result, but in less code...
Are we optimizing a 7-byte program to a 4-byte program now? What's gotten into us? The point was that it didn't work...
My personal guess is that you wreck the stack in some way, or don't realise that your program is in fact doing as it should (might not apply, but I have seen numerous people doing that).
Re:Good way to end a beginning process.
Posted: Sun Oct 24, 2004 3:44 pm
by Dreamsmith
Candy wrote:Are we optimizing a 7-byte program to a 4-byte program now? What's gotten into us? The point was that it didn't work...
Heh. Well, I thought the problem might be he wasn't expecting a continuous stream of INT 33's -- the fact that the code could also be optimized was supposed to be secondary.
I'm sure the fact that I'm obsessive-compulsive about wasted RAM has nothing to do with it...
[You try squeezing useful programs into 64K of address space for a few years, see how your sanity stands up...]
Re:Good way to end a beginning process.
Posted: Sun Oct 24, 2004 4:52 pm
by Colonel Kernel
Maybe I'm missing something here, but why is it necessary to modify the instruction stream just to kill a process? Why not implement a system call for this purpose? The process makes the system call, the kernel gets control and realizes that it shouldn't schedule that process any more, cleans it up, and it never runs again... Your user-mode run-time library should be responsible for making the call after "main" (or its equivalent) returns.
Re:Good way to end a beginning process.
Posted: Mon Oct 25, 2004 6:22 am
by stonedzealot
Sure, that'd be ideal, but right now I want to focus on the scheduler and making sure that's in usable condition before I worry about process death.