From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21250 invoked by alias); 15 Jan 2010 23:17:13 -0000 Received: (qmail 21240 invoked by uid 22791); 15 Jan 2010 23:17:13 -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; Fri, 15 Jan 2010 23:17:07 +0000 Received: (qmail 9095 invoked from network); 15 Jan 2010 23:17:05 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 15 Jan 2010 23:17:05 -0000 Date: Fri, 15 Jan 2010 23:17:00 -0000 From: Daniel Jacobowitz To: Matt Fischer Cc: gdb@sourceware.org Subject: Re: ARM signal trampolines Message-ID: <20100115231656.GA31325@caradoc.them.org> Mail-Followup-To: Matt Fischer , gdb@sourceware.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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/msg00144.txt.bz2 On Fri, Jan 15, 2010 at 04:46:52PM -0600, Matt Fischer wrote: > 1.  When delivering a signal, ARM Linux constructs a stack frame with > a return address pointing to a trampoline in the vector table > (0xffff0500-0xffff0514), which in turn issues a syscall back into the > kernel.  GDB has unwinders for this, but it looks like they have a > couple problems. >    a.  There is no unwinder for a return to Thumb code > (SWI_THUMB_SIGRETURN in arch/arm/kernel/signal.c.) Looks that way. This code doesn't matter though... GLIBC always sets SA_RESTORER. What C library are you using that could trigger this at all? >    b.  The normal EABI unwinder (arm_eabi_linux_sigreturn_tramp_frame) > seems to be incorrect as well.  It expects to see 0xe3a07077 > 0xef000000 (ARM_SET_R7_SIGRETURN followed by ARM_EABI_SYSCALL.) > However the kernel's vector table tries to be cute, and overlaps the > EABI return sequence with the OABI syscall instruction, meaning that > what's actually in the vector table is 0xe3a07077 0xef900077. > Therefore, it doesn't match correctly. 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. > 2.  A bigger problem, though, is that GDB can't seem to read the > vector table area at all.  Any attempt to examine that memory area > results in garbage values.  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.  This makes it seem as though the kernel just doesn't let > you read that region via ptrace() at all. That's correct. There's a workaround for single-stepping through the atomic operations on the same vector page, for this reason. The correct solution depends on whether the signal trampolines are at an ABI-fixed address. If they are, we could hardcode them. Otherwise, someone has to stop putting off making the page ptrace readable. -- Daniel Jacobowitz CodeSourcery