How to understand the strange parameter values shown by 'pstack core'

Question

I encounterred a problem that led to a core dump. I use 'pstack core' to shown the calling stack.
However I could hardly understand some of the parameter values below:
core 'core.150108' of 5016:     cmcfun
ff1e1370 __1cLComEndPointFsendv6MpnFiovec_i_i_ (c, ffbfedf8, 2, 2, c, 0) + 4
Why did the 'this' pointer of the instance of class ComEndPoint become 0xc? I don't think it is a valid value of pointer. Does anybody have any idea about this problem?
ff1e5b00 __1cYComTransaction_Icallback6FpnPpdo_transaction_pcii_v_ (6ab90, 0, 0, 0, ffbff1b8, 0) + dc
According to the source code, the 3rd parameter in the function below, which value is 0x66, was not changed in the scope of the function. However it became 0x0 when it was used as the 4th parameter to call the function above. What't the matter?
ff1528e8 pdo_dispatch (6ab90, ad, 66, 0, 0, 0) + dc
I heard that Sun C++ uses 'register windows' to pass the parameters, i0~i5 are used for the first 6 ones. Somebody told me that what I saw in the pstack might not be creditable because the registers might be changed within the function. Is that so? Would anybody plz tell me more details?
Thanks in advance.
Edited by: DirtyBear on Feb 15, 2008 1:17 AM

Answer 1

Register windows are a property of the SPARC computer architecture, not a property of a compiler. SPARC has multiple sets of registers. The function call instruction advances the "register window" to reveal the next set of registers, if there is one. If not, the registers are spilled to the stack to free up a window. The function return instruction moves the window back. (It's a purely hardware feature.) Eight of the registers in adjacent windows overlap, the origin of the "window" term. Registers %o0 thorugh %o7 in the caller become registers %i0 through %i7 in the called function.
On SPARC and x64, some function arguments are passed in registers, depending on how many arguments there are and their types. (The x86 architecture has no registers available for passing arguments.) On entry to a function, the parameters passed in registers might be saved on the stack, but do not necessarily need to be saved on SPARC. The Solaris ABI requires that space for the registers be allocated, but the space is not necessarily used.
In a core dump, the actual registers, particularly for functions other than the current one, are not available. The pstack operation doesn't know how many parameters a function has or what type they are. It shows the contents of the first 6 words on the stack that would hold arguments, if there were arguments, and if they were actually saved on the stack.
In optimized code on any platform, the stack area for a variable or argument is not kept up to date. Computations are kept in registers to the extent possible, and saved in memory only when necessary.
On SPARC in particular, the argument values shown in a stack trace need not be accurate.