From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98296 invoked by alias); 28 Apr 2015 11:56:13 -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 98286 invoked by uid 89); 28 Apr 2015 11:56:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pd0-f171.google.com Received: from mail-pd0-f171.google.com (HELO mail-pd0-f171.google.com) (209.85.192.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 28 Apr 2015 11:56:10 +0000 Received: by pdbqd1 with SMTP id qd1so161878117pdb.2 for ; Tue, 28 Apr 2015 04:56:09 -0700 (PDT) X-Received: by 10.70.128.9 with SMTP id nk9mr31437015pdb.58.1430222169162; Tue, 28 Apr 2015 04:56:09 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by mx.google.com with ESMTPSA id fn6sm22424105pab.31.2015.04.28.04.56.07 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 28 Apr 2015 04:56:08 -0700 (PDT) From: Yao Qi To: Sandra Loosemore Cc: Subject: Re: [patch 3/3, nios2] fixes for new implementation of signal handler trampolines References: <55393E8C.8090804@codesourcery.com> <5539412B.2020101@codesourcery.com> Date: Tue, 28 Apr 2015 12:11:00 -0000 In-Reply-To: <5539412B.2020101@codesourcery.com> (Sandra Loosemore's message of "Thu, 23 Apr 2015 12:59:55 -0600") Message-ID: <86618gwjoq.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg01040.txt.bz2 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 =3D (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); > > 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? --=20 Yao (=E9=BD=90=E5=B0=A7)