On Tue, Aug 11, 2009 at 11:37:56PM +0100, raymond.me...@rambler.ru wrote:
> Hi, I need some info in regard to 64-bit process' stack layout.
>
> 1) Below is a daigram of how I think the stack looks like. Can anyone
> tell me if this is correct, and if not, what's missing, etc.
>
> 2) As I understand stack bias serves two purposes:
> one - to allow trap handlers to distinguis between 64-bit and 32-bit
> register window.
> two - to allow access a larger stack area with 13-bit signed constants.
>
> Can someone show me an example how stack bias in a 64-bit process
> allows to access larger stack area vs. 32-bit process with no stack
> bias? Also, on the diagram below, there is an area of 2046 bytes between
> %sp and %sp+BIAS, what is that area used for? Is it reserved for
> something? Does is serve a purpose?
It's not quite like that; the issue is that the load and store instructions
in the SPARC instruction set have a signed immediate field of 13 bits. That
means that you can access an offset relative to a register (like %fp) in the
range [%fp - 4096, %fp + 4095].
By setting the bias to 2047, your allowable offsets move lower, so you can
access:
[%fp + BIAS - 4096 - 2047), %fp + BIAS + (4095 - 2047)]
= [%fp + BIAS - 6143, %fp + BIAS + 2048]
Looking at your picture (which is accurate)
Remember that the "variable size" stuff you show here:
> ## High Address ##
>
> ---------------------------------------------------------
> %fp+BIAS <-- start of previous stack frame
> ---------------------------------------------------------
> %fp+BIAS-1 1st local variable
> ---------------------------------------------------------
> %fp+BIAS-N 2nd local variable, etc.
> ---------------------------------------------------------
**> ~~~ variable size
> ---------------------------------------------------------
> %sp+BIAS+186 if needed, outgoing arguments 6 to ...
> ---------------------------------------------------------
>
>
> %sp+BIAS+138 space for arguments 0 to 5 (6*8=48 bytes)
> ---------------------------------------------------------
> %sp+BIAS+128 struct/union return pointer (8 bytes)
> ---------------------------------------------------------
> window save area for 16 registers
> %sp+BIAS (16*8=128 bytes)
> ---------------------------------------------------------
...
> ## Low Address ##
Is actually the top stack frame's *local variables*. Since things like
alloca() increase %sp in an uncontrolled way, you have to access local
variables through %fp. By biasing the stack pointer (and therefore the
frame pointer, through the magic of register windows), you can have fast
access to 6k of local variables at the minor cost of having a reduced
window of access to the previous stack frame. In practice, you never
need to do much with the previous stack frame anyway.
By making the BIAS odd, you get an easily differentiable stack pointer
effectively for free.
The area between %sp and %sp+BIAS is not used for anything, and has no
purpose. As far as the system is concerned, you aren't allowed to access
anything below %sp+BIAS.
Does that answer your questions?
Cheers,
- jonathan
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
