initial stack setup

[Marcus Brinkmann]

Hi Roland,

I was looking at the glibc startup code, and was trying to figure out
what is wrong with the static start in
sysdeps/mach/hurd/static-start.S, according to this comment in
sysdeps/mach/hurd/init-first.c:

/* XXX This is all a crock and I am not happy with it.
   This poorly-named function is called by static-start.S,
   which should not exist at all.  */
void
_hurd_stack_setup (volatile int argc, ...)

...

Clearly something must set up a stack at some time.  The System V ABI
demands that this is done before the entry point.  OTOH, technical
requirements demand that at least in the suid case, this setup must be
done either by the task itself or by trusted system code.  Thus if we
follow the System V ABI, it can not be done by the task itself, but
must be done by the trusted system code (on Mach, it is the exec
server, on L4 it will be the filesystem containing the program).

If we follow the System V ABI, then the stack start, max size and
layout of the initial data on the stack is chosen (and thus fixed) by
the system code.  To make it configurable, we would have to extend the
system code like it is done with PT_GNU_STACK.

If we let the new task set up the stack itself, the stack start, and
layout of the data on the stack can be freely chosen by the new task.

The latter is what is right now done in the Hurd on Mach, as you wrote
it.  I was planning to do the same, based on the design principle that
we should only do things in system code that can't be done in user
code if doing them in user code gives more flexibility.

So I wanted some code before _start that sets up a stack, and probably
does some further low-level initialization (virtual memory manager,
etc), and that's when I stumbled over the comments above.  I would
like to hear your opinion on this issue.  I don't see a particular
value in following this specific aspect of the System V ABI slavishly
(I _do_ see a value in re-using glibc's generic code, but this is
possible either way).  Am I missing something?

Thanks,
Marcus