max at bruningsystems.com ??: > Brian Xu - Sun Microsystems - Beijing China wrote: > >> max at bruningsystems.com ??: >> >>> Brian Xu - Sun Microsystems - Beijing China wrote: >>> >>> >>>> Greg Price ??: >>>> >>>> >>>>> >>>>> >>>> I still have the question that who produces those 'bias area' and when? >>>> >>>> >>>> >>>> >>> When the stack pointer is initialized for a thread when the thread is >>> created, >>> the bias is subtracted to get an initial stack pointer value. Again, >>> see the code >>> in thread_load() which is (at least) one place where the stack >>> pointer is initialized. >>> >>> >> I saw the code you referred. It is only about the thread init. then >> how about the following calls in the thread? >> >>>> It is obvious that before or just after the 'save' instruction, the >>>> %sp has been moved to the bottom of the bias. so it must be the >>>> 'call' or the 'save' instruction that does it. I want to know. >>>> >>>> >>>> >>> No. The save instruction doesn't need to do anything with the stack >>> pointer as far as the >>> bias is concerned. The bias is already "in" the stack pointer when >>> the save is executed. >>> The call also does not need to do anything with the stack pointer. >>> It is only when code >>> needs to access/store data on the stack, and when the thread is >>> initialized, that the >>> bias value needs to be used. >>> >>> >> I think it is only the case for the first call in the thread. For the >> following calls, there must somewhere that implicitly modify the %sp. >> > No. Let's say that several functions are called, each with > save/restore, and each with > minimum 64-bit frame size of 0xb0 bytes. So, a() calls b() which in > turn calls c() which calls d(). > Also assume that the stack starts at (highest address) 0x10000. The > initial stack pointer is at > 0x10000-0x7ff (beginning of stack minus bias). > So, a() does a save %sp, -0xb0, %sp. The stack pointer is now at > 0x10000-0x7ff-0xb0. > If a() needs to access its' save area, it would use, for example, > %sp+0x7ff to access the > save area for %l0, %sp+7ff+8 to access %l1, %sp+7ff+0x10 to access %l2, etc. > Now a() calls b(). b() executes a save %sp, -0xb0, %sp. The current > stack pointer > is now at 0x10000-7ff-b0-b0. For b() to access its' save area, it would > use exactly the > same offsets that a() used to access its' save area, i.e., %sp+7ff for > %l0, %sp+7ff+8 for %l1, etc. > If b() calls c(), the same thing occurs (again, assuming minimum stack > size). > When b() returns, the restore pops (i.e., adds) 0xb0 bytes to the stack > pointer, and > you are back to the (bias adjusted value) of a()'s stack pointer. > In general, there is no need to implicitly (or explicitly except for the > save instruction) modify > the value of the %sp register itself. Code that is using %sp to access > stack locations > must take the bias into account. > > I suddenly know after I read the doc Greg sent to me. It is just the definion of the %sp by the ABI that confuses me.
Thank you so much for the patient teaching. Brian > A diagram would help here immensely... > > max > > _______________________________________________ > mdb-discuss mailing list > mdb-discuss at opensolaris.org >
