On Mon, 2013-04-22 at 16:38 -0700, Jay Lan wrote: Jay, here's an excerpt from an email I answered in 2006. It's not clear that I remember anything about this now :-) Hope it helps. Bob Montgomery -------------------------------- There are three big secrets: 1) The saved values of the stack frame registers (r32, r33, ... up to the limit set by the alloc statement at the beginning of the function for that frame) are located at the Backing Store Pointer (BSP) shown for the frame. If you want to see r32, r33, r34, r35 for frame #8, do crash> x/4xg 0xe00000404ae490e8 2) The saved values of the stack frame registers are their current values, not necessarily the values passed in to the function (for those registers that were used as input registers, for example). In other words, the first parameter is passed as r32, but r32 might be modified by that function before the point in the code represented by the stack trace. Check for this by disassembling: crash> dis mdc_replay_open | grep r32 and looking to see where (if ever) r32 is modified (appears on the left hand side of an "=") in that function. 3) Every 64th word in the backing store is a NaT register store, not a regular register. So when you're counting words from the BSP pointer for that frame to match up with registers, skip any word whose address ends in 0x1f8, 0x3f8, 0x5f8, ... crash is trying to show you the passed parameters. If that's working, those values in parentheses at each level should correspond to r32, r33 ... for as many as shown. If I remember right, crash doesn't do that very well for functions in modules. ---------------------------------------------------------------

Hi Dave, They will only be the contents of the input registers in a local function after they were rotated during a function call at the point in time where they were saved/spilt to the RSE. What they may contain is really determined by the ABI/compiler/calling convention and I don't know if Linux or the compiler options used to compile the kernel dictate that the input registers can be reused or not. When a function starts usually the first instruction is an alloc instruction which allocates input, local, output registers in the RSE (input and local are really combined). When use the call instruction the RSE automatically renumbers the rotating registers so the output registers start from r32 and the caller uses alloc to formalize its RSE usage (defining the callers outputs as inputs to the callee). Although r32 is the first argument register if the callee wants to reuse the register it could, for example it only needs the argument initially and after that it can be reused as a general register (if the compiler is willing to do it). If they were reused you'd need to look at where they came from in in the caller or saved somewhere (onto the memory stack, into another register, or used in a calculation that you can undo, etc). To be really safe you'd really need to disassemble the function they're used in and verify that what you are about to rely on hasn't been modified or replaced by a different value. Thanks Shane -----Original Message----- From: crash-utility-bounces(a)redhat.com [mailto:crash-utility-bounces@redhat.com] On Behalf Of Dave Anderson Sent: Wednesday, April 24, 2013 6:29 AM To: Montgomery, Bob; Discussion list for crash utility usage, maintenance and development Subject: Re: [Crash-utility] How do I get IA64 register R32 and above? ----- Original Message ----- The "bt -f" option uses the rse_function_params() function backported from the kernel's ia64 unwind facility. And they do appear to be as you described, i.e., at the BSP address location. For example: crash> bt -f PID: 1 TASK: e0000100ff118000 CPU: 0 COMMAND: "init" #0 [BSP:e0000100ff119358] schedule at a000000100678b90 (void) #1 [BSP:e0000100ff119328] schedule_timeout at a00000010067a1b0 (1388) #2 [BSP:e0000100ff119250] do_select at a0000001001b0090 (e0000100fe518180, e0000100ff11fce0, e0000100ff11fe10) #3 [BSP:e0000100ff1191f0] core_sys_select at a0000001001b0990 (b, 60000fffffdf77a8, 0, 0, e0000100ff11fe10) #4 [BSP:e0000100ff119160] sys_select at a0000001001b18b0 (b, 60000fffffdf77a8, 0, 0, 60000fffffdf7828) #5 [BSP:e0000100ff119160] ia64_ret_from_syscall at a00000010000be40 EFRAME: e0000100ff11fe40 B0: 400000000000aee0 CR_IIP: a000000000010620 CR_IPSR: 00001213085a6010 CR_IFS: 0000000000000005 AR_PFS: c000000000000005 AR_RSC: 000000000000000f AR_UNAT: 0000000000000000 AR_RNAT: 0000000000000000 AR_CCV: 0000000000000000 AR_FPSR: 0009804c8a70033f LOADRS: 0000000000c00000 AR_BSPSTORE: 600007ffffdfc138 B6: 20000000002cb1a0 B7: a00000010000fc20 PR: 0000000000026241 R1: 2000000000328238 R2: a000000000010640 R3: e0000100ff11fef8 R8: 0000000000000001 R9: 0000000051763204 R10: 0000000000000000 R11: c000000000000611 R12: 60000fffffdf7670 R13: 20000000003b55f0 R14: a000000100707f18 R15: 0000000000000441 R16: e0000100ff118000 R17: 000000000000003f R18: a00000010000fc20 R19: 000000000000011d R20: 0009804c8a70033f R21: 0009804c8a70033f R22: 0000000000000000 R23: 600007ffffdfc138 R24: 0000000000000000 R25: 0000000000000000 R26: c000000000000002 R27: 000000000000000f R28: a000000000010620 R29: 00000010085a2010 R30: 0000000000000005 R31: 0000000000026241 F6: 000000000000000000000 F7: 000000000000000000000 F8: 000000000000000000000 F9: 000000000000000000000 F10: 000000000000000000000 F11: 000000000000000000000 #6 [BSP:e0000100ff119160] __kernel_syscall_via_break at a000000000010620 crash> So if I look at the BSP location for the sys_select() frame #4: #4 [BSP:e0000100ff119160] sys_select at a0000001001b18b0 (b, 60000fffffdf77a8, 0, 0, 60000fffffdf7828) the arguments match up: crash> rd e0000100ff119160 5 e0000100ff119160: 000000000000000b 60000fffffdf77a8 .........w.....` e0000100ff119170: 0000000000000000 0000000000000000 ................ e0000100ff119180: 60000fffffdf7828 (x.....` crash> I would presume that even if they were modified in sys_select() that rse_function_params() would still reflect the arguments as they were passed in to the function. Otherwise, what's the point of the function? And I don't know why it would behave any differently for a module function? Dave -- Crash-utility mailing list Crash-utility(a)redhat.com https://www.redhat.com/mailman/listinfo/crash-utility