From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18632 invoked by alias); 21 May 2012 22:34:01 -0000 Received: (qmail 18570 invoked by uid 22791); 21 May 2012 22:33:58 -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 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 22:33:42 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1SWbAc-0006AK-2p from Maciej_Rozycki@mentor.com ; Mon, 21 May 2012 15:33:42 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 May 2012 15:33:22 -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 23:33:40 +0100 Date: Mon, 21 May 2012 22:34:00 -0000 From: "Maciej W. Rozycki" To: Michael Eager CC: "gdb-patches@sourceware.org" Subject: Re: MIPS Linux signals In-Reply-To: <4FBA879F.2020107@eagerm.com> Message-ID: References: <4FB850CA.7090701@eagerm.com> <4FBA879F.2020107@eagerm.com> 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/msg00796.txt.bz2 On Mon, 21 May 2012, Michael Eager wrote: > > What target are you specifically referring to? Can you describe a > > scenario where it happens? > > Debugging a MIPS core file. Pedro suggested that no one > would ever see this running gdbserver. Well, these are mutually exclusive -- you can't open a remote target and a core file both at a time, and it's only the signal number that's recorded in the core image as the cause of termination that's causing trouble. I wonder if there's more stuff there actually that needs mapping. > > Ah, so that is with the core file target used in a cross-debugger, right? > > Well, no wonder nobody has noticed, this is a very unusual scenario -- I > > have used GDB for at least 15 years now and may have had a need to examine > > a core file with a cross-debugger perhaps once or twice -- and then some > > common signals looked for like SIGSEGV or SIGILL are identity mapped (and > > I knew the signal that caused the core file dumped beforehand anyway as > > it's printed as the program is being killed anyway). > > Yes, this may be less common than I first thought. SEGVs are much > more common than SIGBUS. Actually you'll only see SIGBUS in two cases under MIPS/Linux: 1. An unaligned memory access -- these trap into the kernel if not made correctly (with the special unaligned access instructions) and are normally emulated by the kernel at a large performance expense for data accesses. You can still get one if you try to execute unaligned instructions (e.g. MIPS16 code on a processor that does not support that mode of execution; MIPS16 code addresses have the lowest bit set), try to access unaligned data outside the user address space (USEG or XUSEG as applicable; the lack of alignment takes precedence over MMU protection) or if you disable the kernel emulation with the obscure syscall that's there for special cases. 2. You actually get a true bus error signalled by system logic in an external bus transaction, e.g. an uncorrected memory ECC error or suchlike. As you can see it's all pretty obscure and uncommon stuff. > > Also by the look of it, such changes will actually be required for all > > processor/OS targets as obviously when you have e.g. a MIPS/IRIX-host > > cross-debugger targetting i386/Linux then the signal numbers won't match > > again, except that in the other direction. That certainly begs for a > > general solution, perhaps like one used by the RSP where the GDB core uses > > generic signal numbers the target side translate to/from them as > > appropriate (obviously the host OS may have no notion of signals at all). > > Yes. > > I'm not sure about creating a generic solution. The same solution can > be adapted to Solaris or other OS's which have different signal value > assignments, but a solution for a target which doesn't have signals, > that would call for a target-based (i.e., gdbserver or core generation) > solution. Targets with no signals are not a problem, they simply won't produce or accept any. It's the hosts that are a problem -- generic code in common/signals.c has stuff like this: #if defined (SIGHUP) case TARGET_SIGNAL_HUP: return SIGHUP; #endif that obviosuly won't work on on a host that doesn't have such a signal defined (I'm not sure if hosts like MinGW or DJGPP pretend that these signals exist there, that would make little sense; there may be others as well). As long as every target that supports signals provides its mapping similar to one you did, then I think we should be fine. And actually, as far as Linux is concerned, I suppose we can actually have a common mapping that will cover most of the processor architectures Linux supports as most if not all of the modern ports have standardised on a common set of magic numbers, as far as I know. So linux-tdep.c would default to that standard mapping and then any oddball port would override that choice with their own. It's only the few older ports that had their reasons, legitimate or not, to stick to other definitions that are different -- for the MIPS port for example there used to be an idea once to run IRIX binaries using a foreign kernel personality and an ABI compatibility layer (similar to iBCS the i386/Linux port used to support) -- reusing the same magic numbers would certainly make the effort easier (many kernel structures exposed via syscalls are like those from IRIX rather than other Linux ports for the very same reason). To the best of my knowledge this idea never fully materialised, but these provisions have stayed for backwards compatibility with the early decisions. Another example is the Alpha/Linux port and its actual possibility to run DEC OSF/1 (or Digital Unix or Tru64 Unix or whatever, hmm, lost track...) binaries; these are not ELF even, but ECOFF. There are probably a few more ( suggests SunOS and Solaris, presumably on SPARC and HP-UX presumably on HP-PA), but the rest should be pretty uniform. Maciej