From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27526 invoked by alias); 21 May 2012 17:10:28 -0000 Received: (qmail 27399 invoked by uid 22791); 21 May 2012 17:10:22 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,TW_FC X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 May 2012 17:10:09 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1SWW7U-0001jT-5J from Maciej_Rozycki@mentor.com ; Mon, 21 May 2012 10:10:08 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 May 2012 10:10:07 -0700 Received: from [172.30.0.105] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Mon, 21 May 2012 18:10:05 +0100 Date: Mon, 21 May 2012 17:10:00 -0000 From: "Maciej W. Rozycki" To: Eli Zaretskii CC: Subject: Re: [PATCH] MIPS/Linux: Signal frame support for DSP registers In-Reply-To: <83wr45xzq9.fsf@gnu.org> Message-ID: References: <83wr45xzq9.fsf@gnu.org> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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 X-SW-Source: 2012-05/txt/msg00777.txt.bz2 On Mon, 21 May 2012, Eli Zaretskii wrote: > > Eli, can you tell me if the NEWS entry is OK with you? > > Yes, thanks. Great! I'll push the change then. > > Please note that I deliberately say "Linux" rather than "GNU/Linux" > > here as all the DSP support relies on a kernel feature; it does not > > rely on any C library or other userland feature whatsoever. > > Hmm... since you mention that, I looked into configure.tgt and saw > that we are inconsistent here: some targets are described as running > "GNU/Linux", others just "Linux". Personally, I think "GNU/Linux" is > the more correct in this case (you refer to a target system), but it's > not my call. After some thinking I've concluded it's an interesting question actually. Some target properties are libc-specific, for example the system library is free to map any magic numbers used for kernel syscalls however it likes (things like fcntl flags or whatever) and the library calls may not identity map to syscalls, so these will be libc- rather than kernel-specific. Here I don't think the system library can do anything, the signal frame and the associated bits are arranged by the kernel directly and the layout of struct ucontext_t is cast in stone. One can stuff a hypothetical BSD C library on top of the Linux kernel and our MIPS DSP support will work with that unchanged. A less hypothetical case is an embedded app running on Linux without libc and I believe such stuff actually exists (and GDB can debug it provided that they have a remote stub of some sort available). Thanks for your notes. Maciej