Re: [PATCH 0/2] Display local variables & function parameters fromstack frames

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dave
We had some observation with x86_64 dumps and wanted to know your opinion on them On x86_64 dumps for active processes we are reading the register content from ELF Notes and we found that register content doesn't match with observed output of bt command. SP and IP register content we got from ELF_NOTES are breaking the code when we do stack unwinding, using information from dwarf section, while the unwinding, atleast the first stage, works with SP and IP got from bt way. This issue is similar to gdb, gdb too breaks when unwinding is attempted on this dump.

	I wanted to know what you think about this and how can we proceed.

1. Is it reliable way to parse through the stack frame looking for valid address as is done in 'x86_64_get_dumpfile_stack_frame'. Is it the right/safe way to do, does any x86_ABI talks about ? 2. It looks like we can't safely rely on ELF_NOTES, is this a known issue with kexec dumping ? 3. If Parsing the stack frame is the right thing to do, can we modify bt_cmd routines so as to reuse some of the routines for repopulating our register contents, especially esp/eip.

Scenario We are Facing
------------------------
Register Content from ELF_NOTES: Matches with gdb out put

crash> local display

 IP: 	ffffffff80255d7b
 ax: 	1
 bx: 	0
 cx: 	6237
 dx: 	0
 sp: 	ffff88020f471dc8 <=== Breaks unwinding
 bp: 	0
 si: 	0
 di: 	ffffffff80596ec0
 cs: 	10
 oirg_ax: 	8241000001b6
 flags: 	46
 ip: 	ffffffff80255d7b
 r8: 	0
 r9: 	ffff880028080c80
 r10: 	ffff880028080c80
 r11: 	d805926f0
 r12: 	63
 r13: 	0
------------------------
crash> bt
PID: 4814   TASK: ffff8802104397f0  CPU: 3   COMMAND: "bash"
 #0 [ffff88020f471cf0] machine_kexec at ffffffff8021db38
 #1 [ffff88020f471dc0] crash_kexec at ffffffff80255d9c
 #2 [ffff88020f471e80] __handle_sysrq at ffffffff80385756
 #3 [ffff88020f471ec0] write_sysrq_trigger at ffffffff802d291b
 #4 [ffff88020f471ed0] proc_reg_write at ffffffff802cca2d
 #5 [ffff88020f471f10] vfs_write at ffffffff8029125d
 #6 [ffff88020f471f40] sys_write at ffffffff802916e5
 #7 [ffff88020f471f80] system_call_fastpath at ffffffff8020be0b
    RIP: 000000311bcc4150  RSP: 00007fff976f40d0  RFLAGS: 00010202
    RAX: 0000000000000001  RBX: ffffffff8020be0b  RCX: 00000000000003e
4
    RDX: 0000000000000002  RSI: 00007f428f6ec000  RDI: 000000000000000
1
    RBP: 0000000000000002   R8: 00000000ffffffff   R9: 00007f428f6d86e
0
    R10: 0000000000000072  R11: 0000000000000246  R12: 000000311bf4d76
0
    R13: 00007f428f6ec000  R14: 0000000000000002  R15: 000000008f6ec00
0

Regards
Sharyathi N

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility

[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux