From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24149 invoked by alias); 19 Jan 2010 04:04:16 -0000 Received: (qmail 24065 invoked by uid 22791); 19 Jan 2010 04:04:14 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 19 Jan 2010 04:04:06 +0000 Received: (qmail 26797 invoked from network); 19 Jan 2010 04:04:03 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 19 Jan 2010 04:04:03 -0000 Date: Tue, 19 Jan 2010 04:04:00 -0000 From: Daniel Jacobowitz To: Matt Fischer Cc: gdb@sourceware.org Subject: Re: ARM signal trampolines Message-ID: <20100119040354.GA18523@caradoc.them.org> Mail-Followup-To: Matt Fischer , gdb@sourceware.org References: <20100115231656.GA31325@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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/msg00165.txt.bz2 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. Is there > some other change which has been made to this mechanism in more recent > kernels? I may be confused. I thought it previously copied code to the stack, and only recently started putting it on the vector page. > Given what you've said, the easiest thing to do for my purposes is > probably just to patch Bionic to use SA_RESTORER. Then I can just > ensure the trampoline is constructed to match what's already in there > for glibc, and things should all work out. I 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. > Long term, though, it would certainly be nice if gdb could see the > vector page--I've run into a couple situations where I've needed to > see what was in there, and gdb wasn't able to help. It seems like the > kernel patch to do this wouldn't be overly complicated--is there some > reason that this isn't a desirable feature, or is it just that > nobody's had a pressing enough need for it so far? I think it's just not been needed. -- Daniel Jacobowitz CodeSourcery