[Bug 273688] sysutils/pstack: does not work with Valgrind
- In reply to: bugzilla-noreply_a_freebsd.org: "[Bug 273688] pstack does not work with Valgrind"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 24 Sep 2023 20:16:37 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273688 --- Comment #3 from Paul Floyd <pjfloyd@wanadoo.fr> --- procReadThread() is what I meant (gdb) info frame Stack level 0, frame at 0x1002ca9d90: rip = 0x381a03a6 in vgModuleLocal_do_syscall_for_client_WRK (m_syswrap/syscall-amd64-freebsd.S:144); saved rip = 0x3819f27a called by frame at 0x1002ca9ea0 source language asm. Arglist at 0x1002ca9d80, args: Locals at 0x1002ca9d80, Previous frame's sp is 0x1002ca9d90 Saved registers: rbp at 0x1002ca9d80, rip at 0x1002ca9d88 procReadThread breaks from the first pass through the loop. Here's a printf that I added DEBUG: procReadThread bp 1002024f20 <= frame->bp 1002ca9d80 Back over in gdb current rbp: (gdb) p $rbp $5 = (void *) 0x1002ca9fa0 (gdb) info frame 0 Stack frame at 0x1002ca9d90: rip = 0x381a03a6 in vgModuleLocal_do_syscall_for_client_WRK (m_syswrap/syscall-amd64-freebsd.S:144); saved rip = 0x3819f27a called by frame at 0x1002ca9ea0 source language asm. Arglist at 0x1002ca9d80, args: Locals at 0x1002ca9d80, Previous frame's sp is 0x1002ca9d90 Saved registers: rbp at 0x1002ca9d80, rip at 0x1002ca9d88 (gdb) info frame 1 Stack frame at 0x1002ca9ea0: rip = 0x3819f27a in do_syscall_for_client (m_syswrap/syswrap-main.c:368); saved rip = 0x3819b150 inlined into frame 2, caller of frame at 0x1002ca9d90 source language c. Arglist at unknown address. Locals at unknown address, Previous frame's sp is 0x1002ca9d90 Saved registers: rbp at 0x1002ca9d80, rip at 0x1002ca9d88 (gdb) info frame 3 Stack frame at 0x1002ca9f10: rip = 0x3819b150 in handle_syscall (m_scheduler/scheduler.c:1206); saved rip = 0x38199223 called by frame at 0x1002ca9fb0, caller of frame at 0x1002ca9ea0 source language c. Arglist at 0x1002ca9ea0, args: tid=tid@entry=1, trc=trc@entry=73 Locals at 0x1002ca9ea0, Previous frame's sp is 0x1002ca9f10 Saved registers: rbx at 0x1002ca9ef0, rbp at 0x1002ca9f00, r14 at 0x1002ca9ef8, rip at 0x1002ca9f08 I'm beginning to wonder if the saved $rbps aren't just nonsense and whether gdb and lldb are getting their stack traces from debuginfo. Valgrind is a bit of a monster. On startup (it's own _start in assembler) it allocates its own small bootstrap stack of 1M. Once it has done all its initialization it allocates another stack with guard pages and does a stack transfer to that stack via a mov to rsp then a ret. The new stack appears from then on as the bottom of the callstack. On top of that, the callstack that I've been looking at consists of assembler funcion inlined C function C function called via longjmp then "normal" C functions up to the re-rooted bottom of callstack. It looks like the strange $rbp happens after the longjmp. -- You are receiving this mail because: You are the assignee for the bug.