From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7146 invoked by alias); 18 Jan 2010 22:27:31 -0000 Received: (qmail 7137 invoked by uid 22791); 18 Jan 2010 22:27:30 -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-gx0-f210.google.com (HELO mail-gx0-f210.google.com) (209.85.217.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 18 Jan 2010 22:27:25 +0000 Received: by gxk2 with SMTP id 2so3412400gxk.4 for ; Mon, 18 Jan 2010 14:27:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.101.4.36 with SMTP id g36mr10524071ani.75.1263853643217; Mon, 18 Jan 2010 14:27:23 -0800 (PST) In-Reply-To: <20100115231656.GA31325@caradoc.them.org> References: <20100115231656.GA31325@caradoc.them.org> Date: Mon, 18 Jan 2010 22:27: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/msg00162.txt.bz2 On Fri, Jan 15, 2010 at 5:17 PM, Daniel Jacobowitz w= rote: > Looks that way. =A0This code doesn't matter though... =A0GLIBC always sets > SA_RESTORER. =A0What C library are you using that could trigger this > at all? I'm working on an Android system. Bionic doesn't seem to bother with SA_RESTORER--it just wires sigaction() straight up to the syscall, so unless you specify your own, the kernel sets up the stack frame with a return address pointing to the trampolines on the vector page. > None of this code is for the vector area trampolines which are brand > new. =A0Just a few months old, I believe. =A0It 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? >> 2.=A0 A bigger problem, though, is that GDB can't seem to read the >> vector table area at all.=A0 Any attempt to examine that memory area >> results in garbage values.=A0 Indeed, I can't even seem to get ptrace() >> to read that memory area in any process--any attempt to do so just >> returns -1.=A0 This makes it seem as though the kernel just doesn't let >> you read that region via ptrace() at all. > > That's correct. =A0There's a workaround for single-stepping through the > atomic operations on the same vector page, for this reason. =A0The > correct solution depends on whether the signal trampolines are at an > ABI-fixed address. =A0If they are, we could hardcode them. =A0Otherwise, > someone has to stop putting off making the page ptrace readable. 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. 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? --Matt