(forw) Prototype for libc-provided signal trampolines

Alfred Perlstein · *nix forums addict Joined: 19 Mar 2002 Posts: 67

In case you haven't seen this, it was recently posted on the NetBSD
lists about how they seem to return from the scheduler activation
upcall...

----- Forwarded message from Jason R Thorpe <thorpej@wasabisystems.com> -----

From: Jason R Thorpe <thorpej@wasabisystems.com>
To: tech-kern@netbsd.org
Subject: Prototype for libc-provided signal trampolines
Date: Sat, 22 Jun 2002 15:10:14 -0700
Message-ID: <20020622151014.I6276@dr-evil.shagadelic.org>
Mail-Followup-To: Jason R Thorpe <thorpej@wasabisystems.com>,
tech-kern@netbsd.org
User-Agent: Mutt/1.2.5i
Organization: Wasabi Systems, Inc.
Sender: tech-kern-owner@netbsd.org

The following is a prototype implementation of the userland signal
trampoline I mentioned in my "nathanw_sa TODO list". This strategy
for signal trampolines can (and, I think, should) be used for the
SA upcall trampoline, as well.

Here are the rules of the new interface:

* Arch-dependent code in libc provides sigaction(2) entry point
(we get to keep the current entry point, __sigaction14()) and
the signal trampolines. The trampolines are arch-dependent.

* Signal trampolines are versioned, so that if arch-dependent
code in the kernel or in libc needs to change it at some point,
it can be handled without interfering with other architectures.

* Signal trampolines have a well-defined naming scheme:

__sigtramp_<flavor>_<version>

where:

<flavor> The flavor of the handler, the
traditional sigcontext type or
POSIX siginfo type.

<version> The version of the trampoline.

So, for example, all platforms right now would provide
a trampoline named "__sigtramp_sigcontext_1"

The reason for this naming scheme: Debuggers, like gdb,
need this info:

* They need to know if a PC is in a signal trampoline,
and having access to a symbol name REALLY helps in
this regard.

* They need to know if they have a sigcontext (for
sigcontext flavor) or a ucontext_t (for siginfo
flavor), so they can unwind the call graph through
the signal handler. Having this indicated by the
trampoline's name REALLY helps in this regard.

* They need the version info to know what format the
sigcontext/ucontext_t is in.

* The signal trampoline should be invoked with the arguments
already set up for the handler. For example, in the case of
Alpha, the 3 handler args should already been in registers
a0, a1, and a2. For the VAX, the args should already be pushed
onto the stack.

* The pointer to the signal handler should simply be passed in a
"4th argument" slot, for simplicity. This more or less mirrors
what the SA upcall trampoline does on the nathanw_sa branch. For
platforms which provide a special register for this (e.g. the "pv"
register on the Alpha), that register should be used instead.

Now, it so happens that the changes required to do this are quite small.
Attached are the changes for the Alpha port (I've left out changes to
the compat modules, which are simple adjustments to the sigaction1() call),
and all of the generated files.

I'd like to get feedback on this ASAP. It's a simple change we can make
to the mainline before bringing down the SA branch which will make dealing
with forward compatibility much easier.

--
-- Jason R. Thorpe <thorpej@wasabisystems.com>

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message

Google