From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100692 invoked by alias); 28 Apr 2015 15:27:27 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 100682 invoked by uid 89); 28 Apr 2015 15:27:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 28 Apr 2015 15:27:25 +0000 Received: from svr-orw-fem-05.mgc.mentorg.com ([147.34.97.43]) by relay1.mentorg.com with esmtp id 1Yn7Pt-0006PP-Pp from Sandra_Loosemore@mentor.com ; Tue, 28 Apr 2015 08:27:21 -0700 Received: from [IPv6:::1] (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.3.224.2; Tue, 28 Apr 2015 08:27:21 -0700 Message-ID: <553FA69D.90501@codesourcery.com> Date: Tue, 28 Apr 2015 15:47:00 -0000 From: Sandra Loosemore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Yao Qi CC: Subject: Re: [patch 3/3, nios2] fixes for new implementation of signal handler trampolines References: <55393E8C.8090804@codesourcery.com> <5539412B.2020101@codesourcery.com> <86618gwjoq.fsf@gmail.com> In-Reply-To: <86618gwjoq.fsf@gmail.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-04/txt/msg01050.txt.bz2 On 04/28/2015 05:56 AM, Yao Qi wrote: > Sandra Loosemore writes: > >> Earlier versions of the nios2 kernel used to allocate code for signal >> handler trampolines on the stack, but when the port was accepted >> upstream it was changed to instead put the trampoline at a fixed >> address in low memory (0x1044). >> >> Moving the code off the stack changed the layout of the stack frame, >> so the first part of this fix involves updating the offset to the >> register save area. This is not an exported interface from the >> kernel; I noticed e.g. the existing aarch64 gdb support includes a >> huge block of comments explaining the kernel's signal handler stack >> frame layout but ultimately also relies on using magic numbers to >> access the register save area. I used a somewhat smaller block of >> comments for nios2 but I think now it is clear where the magic numbers >> come from and what kernel code this corresponds to. > > We can make this magic number less magic by documenting how it is > calculated. We did something similar in > tic6x-linux-tdep.c:tic6x_linux_rt_sigreturn_init, > > /* The base of struct sigcontext is computed by examining the definition of > struct rt_sigframe in linux kernel source arch/c6x/kernel/signal.c. */ > CORE_ADDR base = (sp + TIC6X_SP_RT_SIGFRAME > /* Pointer type *pinfo and *puc in struct rt_sigframe. */ > + 4 + 4 > + TIC6X_SIGINFO_SIZE > + 4 + 4 /* uc_flags and *uc_link in struct ucontext. */ > + TIC6X_STACK_T_SIZE); Well, ahem, the magic number was actually calculated by inspection of the stack from the debugger. :-) I got lost trying to calculate the sizes of the data structures (struct siginfo, etc) from the kernel code by hand, and what purpose would it serve to have more magic numbers that are harder to compute than the current one? >> The second problem is that the trampoline is not writable by user >> processes so GDB cannot set software breakpoints there. I've tried to >> deal with that in the single-step hook by having it effectively step >> over the trampoline by setting the breakpoint on its return address, >> but for operations like "finish" or "advance" that use the stack >> unwinder to get the location to set the breakpoint, it seems like >> there is nothing to do but kfail the tests. > > Could you address this in a separated patch? Yes, I can split the patch. -Sandra