From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752966AbbBYLfo (ORCPT ); Wed, 25 Feb 2015 06:35:44 -0500 Received: from mail-we0-f173.google.com ([74.125.82.173]:37925 "EHLO mail-we0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751641AbbBYLfl (ORCPT ); Wed, 25 Feb 2015 06:35:41 -0500 Message-ID: <54EDB2FC.4050901@vanguardiasur.com.ar> Date: Wed, 25 Feb 2015 08:33:16 -0300 From: Ezequiel Garcia Organization: VanguardiaSur User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Arnd Bergmann CC: Tobias Klauser , Chung-Ling Tang , Walter Goossens , Ley Foon Tan , linux-arch@vger.kernel.org, "nios2-dev@lists.rocketboards.org" , "linux-kernel@vger.kernel.org" Subject: Re: nios2: is the ptrace ABI correct? References: <5636312.0WGrbVlVgB@wuerfel> <54EC98A9.9080203@vanguardiasur.com.ar> <10088870.tldQegtTla@wuerfel> In-Reply-To: <10088870.tldQegtTla@wuerfel> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/24/2015 04:25 PM, Arnd Bergmann wrote: > On Tuesday 24 February 2015 12:28:41 Ezequiel Garcia wrote: >> >> Gah, no, you are right. I got confused. >> >> So it would be OK to avoid remove pt_regs from the uapi headers? >> How does this affect the signal handling nios2 implementation? >> > > We have a number of architectures that don't provide this structure: > > $ git grep -L pt_regs arch/*/include/uapi/asm/ptrace.h > arch/frv/include/uapi/asm/ptrace.h > arch/metag/include/uapi/asm/ptrace.h > arch/openrisc/include/uapi/asm/ptrace.h > arch/s390/include/uapi/asm/ptrace.h > > so I'd assume it's ok in general not to have it. However, on > nios2, struct pt_regs is embedded inside of struct sigcontext. > If I read the code in arch/nios2/kernel/signal.c correctly, > this is actually a bug and you should use a different structure > there too, because pt_regs does not match the layout of the > stack either. This means that the (rare) user programs that > would know about the architecture to modify signal stacks > are currently broken. > /me is more confused now In arch/nios2/include/asm/ucontext.h struct ucontext { unsigned long uc_flags; struct ucontext *uc_link; stack_t uc_stack; struct mcontext uc_mcontext; sigset_t uc_sigmask; }; And in include/uapi/asm-generic/ucontext.h: struct ucontext { unsigned long uc_flags; struct ucontext *uc_link; stack_t uc_stack; struct sigcontext uc_mcontext; sigset_t uc_sigmask; }; Which one is the one that userspace sees? And why does the kernel has two different structures? Given this oddities, I'm wondering how troublesome would be to just re-do this and break the ptrace and signal ABI. For instance, just pushing pt_regs in PTRACE_GETREGSET would make things much clearer. I guess Linus would burn me for even suggesting to breaking users... but do we have any users at all? This arch has just been mainlined. Altera's out-of-tree is already ABI-incompatible with mainline so that's not an issue. The only one using this ABI is gdb, which is easily fixed. -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar