From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20548 invoked by alias); 19 Jan 2010 15:14:24 -0000 Received: (qmail 20538 invoked by uid 22791); 19 Jan 2010 15:14:23 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-yx0-f180.google.com (HELO mail-yx0-f180.google.com) (209.85.210.180) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 19 Jan 2010 15:14:18 +0000 Received: by yxe10 with SMTP id 10so2374411yxe.12 for ; Tue, 19 Jan 2010 07:14:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.101.164.4 with SMTP id r4mr11457123ano.189.1263914056904; Tue, 19 Jan 2010 07:14:16 -0800 (PST) In-Reply-To: <20100119040354.GA18523@caradoc.them.org> References: <20100115231656.GA31325@caradoc.them.org> <20100119040354.GA18523@caradoc.them.org> Date: Tue, 19 Jan 2010 15:14:00 -0000 Message-ID: Subject: Re: ARM signal trampolines From: Matt Fischer To: Matt Fischer , gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-01/txt/msg00167.txt.bz2 On Mon, Jan 18, 2010 at 10:03 PM, Daniel Jacobowitz wrote: > On Mon, Jan 18, 2010 at 04:27:23PM -0600, Matt Fischer wrote: >> > None of this code is for the vector area trampolines which are brand >> > new. ?Just a few months old, I believe. ?It is for the SA_RESTORER >> > functions in glibc. >> >> I guess I'm confused--the code I'm looking at appears to have been in >> the kernel since about 2.6.13--it's the vector of return codes called >> sigreturn_codes[] in arch/arm/kernel/signal.c, which gets copied to >> the vector page by trap_init() in arch/arm/kernel/traps.c. =A0Is there >> some other change which has been made to this mechanism in more recent >> kernels? > > I may be confused. =A0I thought it previously copied code to the stack, > and only recently started putting it on the vector page. > It looks like it also copies it to the stack, but as long as we're running in 32-bit mode, it uses the vector page, so that it doesn't need to do an i-cache flush on the stack (and to reduce the need for an executable stack.) This looks to have been added around 2005. Glibc appears to set a restorer for exactly the same reason, but it predates this kernel logic by several years, so I imagine it was added to work around this problem back in the days of ARM2 or something, before the kernel had the snazzy high memory page. It looks like there is probably not a need for it anymore, since the kernel now does exactly the same thing anyway. >> Given what you've said, the easiest thing to do for my purposes is >> probably just to patch Bionic to use SA_RESTORER. =A0Then I can just >> ensure the trampoline is constructed to match what's already in there >> for glibc, and things should all work out. =A0I don't know if I could >> get it accepted upstream or not, but it should at least allow my local >> testing to work out. > > Yes, that will be easy and should work. > I've implemented this and it seems to work great. Thanks for all your help. --Matt