[Prev][Next][Index][Thread]
Re: Stack in OSKIT
> Hi,
> I just wondered why, when I make the stack of a process to be an independent
> segment, the whole thing crashes with no warning messages or the like? When
> I make the stack a part of DS (like allocating more memory for the DS
> segment than needed and placing the stack just behind the data) everything
> works ok! The two small processes I made just to test this made a simple
> "for" loop, just incrementing a variable, not even "printf"-ing or the
> like... I have no objections to placing the stack in the DS segment, but how
> one detects stack overflows like this?
I have no idea why it is crashing for you. Are you setting up the
segment descriptor properly? You can look at kern/x86/base_gdt_init.c
to see where it initializes the code and data segments, as a reference
point.
Are you using a valid segment descriptor value? Remember, you can't
just pick any number and have it work. Also, the default table is
pretty small, so you may be past the end. If you sent the code you are
using, it would be much easier to help than second-guessing what
you are doing from your message...
The low-level code will not generate any warning messages if used
improperly. It is expected that the programmer will ensure that
the correct values are passed in -- and we don't want low level code
like that doing a printf anyway.
Also, CS and DS in the "base environment" map a 4GB address space,
where virtual==linear==physical. There is no paging, so you can't
detect a stack overflow. The obvious way to allocate a big stack
would be to simply malloc a big chunk and set ESP to the end of the
chunk. Or, you can simply increase the base_stack size (see
examples/x86/tiny_stack.S, and change MY_STACK_SIZE to whatever you
want, and link that)
You can also look at threads/x86/pthread_guard.c, which implements
mprotect using the simple virtual memory lib (svm), and at
unsupported/nullpointer.c, which uses a breakpoint register
to protect a (single) address.
Oh, I take it you are not using the base environment, then, as you
are running processes under the OSKit? Detecting a past-end-of-segment
violation isn't any easier than detecting a normal page fault --
under Unix, DS and SS are generally the same, and the page-fault handler
determines if the stack needs to grow or if it was an invlid (past
sbrk) access based on the VA accessed.
Kevin Van Maren
University of Utah, CSL
=================================
To subscribe or unsubscribe, send mail with "subscribe" or "unsubscribe"
to oskit-users-request@flux.cs.utah.edu. The oskit-announce list is low
volume - if you want to subscribe, mail oskit-announce-request@flux.cs.utah.edu
Follow-Ups: