Is it bad that a process should self create an own stack?

Question

Is it bad that a process should self create an own stack? If a kernel does not want to do it.

Like here

_start:
    mov $stack_head, %rsp
    jmp main

.data
.align 8
stack:
    .quad 0
    .quad 0
    .quad 0
    .quad 0
stack_head:

or using the malloc syscall.

See http://stackoverflow.com/questions/994555/windows-avoid-pushing-full-x86-context-on-stack for a breif discussion of an application programming language that does this scalability reasons. — Ira Baxter, Dec 03 '13 at 15:21
I`am developing a kernel. The kernel want not to manage a stack. I want to know that it will not cause a problem in future. — user2616346, Dec 04 '13 at 06:11
@user2616346: If it's your kernel, it's your rules. It's a bad idea to do this in Windows or Linux because it makes it hard for the stack to dynamically grow, but in your kernel you can make different choices. — Matt, Jan 07 '14 at 17:41

score 1 · Answer 1 · edited Dec 03 '13 at 18:54

No, not as such. Some systems even require it. But it's always a good idea to follow the conventions, if possible.

I don't think it's THAT dangerous - even in linux - to prepare another stack for a program. Linux sets up a stack anyway (unless you explicitly say "no thanks"). But one better be careful not to get confused with the stacks.

A good and beautiful idea it is not, in case of Linux or Windows, because it's against the conventions. Also it's somewhat more (unnecessary) trouble.

In many RTOSes you have to set up the stacks yourself.

score 0 · Answer 2 · answered Dec 03 '13 at 16:04

0

Some OSs even require setting up the stack like this.

However malloc() will not work because functions like malloc() typically require an already set-up stack pointer.

Under Linux - for example - doing it like this is a very bad idea because Linux observes the stack pointer and automatically allocates more memory if required. If you move the stack pointer like this you'll possibly cause a crash of your program.

answered Dec 03 '13 at 16:04

Martin Rosenau

17,897
3
19
38

Crash? Only if you design poorly. If your application has enough stack space set aside, acquired by malloc or any other means, it isn't a program. I have a programming language that does this, with very small heap-allocated stack areas, under Wine. Granted, that's not quite Linux but Wine basically operates by letting your binary code execute natively (including stack operations). Our applications run just fine. – Ira Baxter Dec 03 '13 at 16:23
@IraBaxter: This is true. But when using the stack allocated by the OS the OS will automatically resize the stack when necessary (at least when using Linux); this is not the case when using a self-allocated stack so when the stack is "full" then then a "push" instruction will cause a program crash! – Martin Rosenau Dec 04 '13 at 06:58
("it isn't a program" meant "it isn't a problem). How does Linux know what the stack area for the program is, if it doesn't dictate it? How does that work with multiple threads (I suppose they can also be dictated). As I said before, if the self-allocated stack is sized by the compiler to not overflow, no push can cause a trap. – Ira Baxter Dec 04 '13 at 07:26
A crash only happens if the stack would be exceeded. Fpr user space applications this might be convenient, but it indicates that the requirements for the program may not be well defined. If somebody develops a kernel, he should definitely have a good idea of his code requirements. – Devolus Dec 04 '13 at 12:35

Is it bad that a process should self create an own stack?

2 Answers2