https://bugs.kde.org/show_bug.cgi?id=445032
--- Comment #9 from Paul Floyd <pjfl...@wanadoo.fr> ---
I'm not sure why, but I only intermittently get VTALRM signals when running
under gdb.
thr_sig.c:246 is in
static void
thr_sighandler(int sig, siginfo_t *info, void *_ucp)
Looking at the Valgrind source, this is "called" here (in m_signals.c)
/* Create a signal delivery frame, and set the client's %ESP and
%EIP so that when execution continues, we will enter the
signal handler with the frame on top of the client's stack,
as it expects.
Signal delivery can fail if the client stack is too small or
missing, and we can't push the frame. If that happens,
push_signal_frame will cause the whole process to exit when
we next hit the scheduler.
*/
vg_assert(VG_(is_valid_tid)(tid));
push_signal_frame ( tid, info, uc );
So rather than calling the signal handler, Valgrind is directly manipulating
the client stack and then just resuming execution.
In gdb, I can get some useful debugging done with the separate debuginfo:
(gdb) set directories /usr/src/lib/libthr/thread
and
(gdb) add-symbol-file /usr/lib/debug/lib/libthr.so.3.debug
(they don't seem to be searched for by default on my amd64 system)
Here's the trampoline for the syscall to sigreturn
│ > 0xffffe194 lea 0x20(%esp),%eax
│ 0xffffe198 push %eax
│ 0xffffe199 mov $0x1a1,%eax
│ 0xffffe19e push %eax
│ 0xffffe19f int $0x80
I'm a bit confused as to why the above (calling syscall 417 sigreturn) then
calls thr_sighandler. I would have thought that the handler would be called
first and then sigreturn after the user code. Maybe it's used for both.
I see that the arguments are passed to thr_sighandler in ebx/edi/esi
Something similar can be seen in i386/i386/sigtramp.s
/*
* Signal trampoline, copied to top of user stack
*/
NON_GPROF_ENTRY(sigcode)
calll *SIGF_HANDLER(%esp)
leal SIGF_UC(%esp),%eax /* get ucontext */
pushl %eax
testl $PSL_VM,UC_EFLAGS(%eax)
jne 1f
mov UC_GS(%eax),%gs /* restore %gs */
1:
movl $SYS_sigreturn,%eax
pushl %eax /* junk to fake return addr. */
int $0x80 /* enter kernel with args */
/* on stack */
where
ASSYM(SIGF_UC, offsetof(struct sigframe, sf_uc));
SIGF_UC will be 20 (0x14)
For comparison in Valgrind
lea 0x1c(%esp), %eax /* args to sigreturn(ucontext_t *) */
pushl %eax
pushl %eax /* fake return addr */
movl $__NR_fake_sigreturn, %eax
int $0x80
The Valgrtind version of 'struct sigframe' has an extra Address member at the
beginning.
That gives us an offset of 24 (0x18), but there is also all of the fiddling
with esp that I do in build_sigframe which is where another 4 gets added [24
0x16]. I think.
--
You are receiving this mail because:
You are watching all bug changes.
