Date: Sun, 24 Sep 2023 20:16:37 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 273688] sysutils/pstack: does not work with Valgrind Message-ID: <bug-273688-7788-suF6M99Edd@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-273688-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-273688-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D273688 --- Comment #3 from Paul Floyd <pjfloyd@wanadoo.fr> --- procReadThread() is what I meant (gdb) info frame Stack level 0, frame at 0x1002ca9d90: rip =3D 0x381a03a6 in vgModuleLocal_do_syscall_for_client_WRK (m_syswrap/syscall-amd64-freebsd.S:144); saved rip =3D 0x3819f27a called by frame at 0x1002ca9ea0 source language asm. Arglist at 0x1002ca9d80, args:=20 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 <=3D frame->bp 1002ca9d80 Back over in gdb current rbp: (gdb) p $rbp $5 =3D (void *) 0x1002ca9fa0 (gdb) info frame 0 Stack frame at 0x1002ca9d90: rip =3D 0x381a03a6 in vgModuleLocal_do_syscall_for_client_WRK (m_syswrap/syscall-amd64-freebsd.S:144); saved rip =3D 0x3819f27a called by frame at 0x1002ca9ea0 source language asm. Arglist at 0x1002ca9d80, args:=20 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 =3D 0x3819f27a in do_syscall_for_client (m_syswrap/syswrap-main.c:368); saved rip =3D 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 =3D 0x3819b150 in handle_syscall (m_scheduler/scheduler.c:1206); saved= rip =3D 0x38199223 called by frame at 0x1002ca9fb0, caller of frame at 0x1002ca9ea0 source language c. Arglist at 0x1002ca9ea0, args: tid=3Dtid@entry=3D1, trc=3Dtrc@entry=3D73 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 bootst= rap stack of 1M. Once it has done all its initialization it allocates another s= tack with guard pages and does a stack transfer to that stack via a mov to rsp t= hen 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-273688-7788-suF6M99Edd>