From owner-freebsd-arch Sat Jun 22 16: 8:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 9327937B400; Sat, 22 Jun 2002 16:08:14 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 69119AE305; Sat, 22 Jun 2002 16:08:14 -0700 (PDT) Date: Sat, 22 Jun 2002 16:08:14 -0700 From: Alfred Perlstein To: julian@freebsd.org Cc: arch@freebsd.org, mini@freebsd.org, jake@freebsd.org Subject: (forw) Prototype for libc-provided signal trampolines Message-ID: <20020622230814.GH53232@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 ----- From: Jason R Thorpe 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 , 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__ where: The flavor of the handler, the traditional sigcontext type or POSIX siginfo type. 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message