[lkml]   [2010]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [GIT] Sparc
From: Al Viro <>
Date: Thu, 23 Sep 2010 05:59:22 +0100

> They do have a reason for doing it that way and it's worth considering on
> other platforms. Think what happens if we are getting traced. We'll be
> stopped and tracer will be notified. Normally it'll tell us to continue
> execution, possibly with a different signal *AND* with a different userland
> address to return to. Suppose we've got a different return address set
> for us (e.g. with PTRACE_POKEUSR). Should we ever shift it back by what
> hopefully is a size of syscall insn?

These "tracer changing the program counter" issues are why on sparc we
have this software state bit in the %tstate/%psr we report via regsets
(and thus via ptrace) to debuggers which tells if we are inside of a
syscall or not.

GDB uses this to know whether the kernel signal handling is going to
modify the program counter or not when the inferior continues.

If GDB ever writes the program counter of the inferior, it clears
this "in-syscall" bit, and this short-circuits the restart syscall
logic in the signal dispatch code.

This is what the GDB code looks like:

static void
sparc_linux_write_pc (struct regcache *regcache, CORE_ADDR pc)
struct gdbarch_tdep *tdep = gdbarch_tdep (get_regcache_arch (regcache));

regcache_cooked_write_unsigned (regcache, tdep->pc_regnum, pc);
regcache_cooked_write_unsigned (regcache, tdep->npc_regnum, pc + 4);

/* Clear the "in syscall" bit to prevent the kernel from
messing with the PCs we just installed, if we happen to be
within an interrupted system call that the kernel wants to

Note that after we return from the dummy call, the PSR et al.
registers will be automatically restored, and the kernel
continues to restart the system call at this point. */
regcache_cooked_read_unsigned (regcache, SPARC32_PSR_REGNUM, &psr);
psr &= ~PSR_SYSCALL;
regcache_cooked_write_unsigned (regcache, SPARC32_PSR_REGNUM, psr);

 \ /
  Last update: 2010-09-27 20:09    [W:0.080 / U:4.712 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site