[Bug 273688] sysutils/pstack: does not work with Valgrind

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.