From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27064 invoked by alias); 22 May 2012 18:31:25 -0000 Received: (qmail 27051 invoked by uid 22791); 22 May 2012 18:31:23 -0000 X-SWARE-Spam-Status: No, hits=-7.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 22 May 2012 18:31:05 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q4MIUxZx019366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 May 2012 14:30:59 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q4MIUvUq008285; Tue, 22 May 2012 14:30:58 -0400 Message-ID: <4FBBDB61.7070002@redhat.com> Date: Tue, 22 May 2012 18:31:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Michael Eager CC: "Maciej W. Rozycki" , "gdb-patches@sourceware.org" Subject: Re: MIPS Linux signals References: <4FB850CA.7090701@eagerm.com> <4FBAB500.7010104@redhat.com> <4FBAB948.7000808@eagerm.com> <4FBB67AE.5090807@redhat.com> <4FBBB352.6080009@eagerm.com> <4FBBB877.8010109@redhat.com> <4FBBD770.6080900@eagerm.com> In-Reply-To: <4FBBD770.6080900@eagerm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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/msg00843.txt.bz2 On 05/22/2012 07:14 PM, Michael Eager wrote: > On 05/22/2012 09:01 AM, Pedro Alves wrote: > >>>> target_signal_from_host => gdb_signal_from_host (or gdb_signal_from_host_signal) >>>> target_signal_to_host => gdb_signal_to_host (or gdb_signal_to_host_signal) >>>> >>>> gdbarch_target_signal_from_host => gdbarch_gdb_signal_from_target (or gdbarch_gdb_signal_from_target_signal) >>>> gdbarch_target_signal_to_host => gdbarch_gdb_signal_to_target (or gdbarch_gdb_signal_to_target_signal) >>> >>> OK, but I'd recommend >>> target_signal_from_host => gdb_signal_from_target >>> target_signal_to_host => gdb_signal_to_target >>> >>> This is symmetric with the gdbarch_ functions and clear that the function >>> translates to/from target system values, not the host system. >> >> >> But it's not what the functions do... They really convert from the host >> system signals, not the target's. I think the symmetry will only lead to >> people getting confused (which one to call in common/target-independent code?). > > If you are running GDB on a Windows host, for example, what host > system signals are you translating? There's only be one such call -- the one from within corelow.c, if there's no gdbarch_target_signal_from_host callback installed. (The Windows ports don't call target_signal_from_host anywhere (windows-nat.c and friends). And in that case, if you e.g., load a cygwin core, the target_signal_from_host fallback will try to convert the signal number as if it was a host signal number. If you're running g b on a cygwin host, you'll happen to get the right values. If you're debugging a core (that same core or of some other non-native arch) with a cross debugger, with a mingw hosted gdb, then target_signal_from_host will _still_ translate the signal numbers found in mingw's signal.h header. For reference, those are: #define SIGINT 2 /* Interactive attention */ #define SIGILL 4 /* Illegal instruction */ #define SIGFPE 8 /* Floating point error */ #define SIGSEGV 11 /* Segmentation violation */ #define SIGTERM 15 /* Termination request */ #define SIGBREAK 21 /* Control-break */ #define SIGABRT 22 /* Abnormal termination (abort) */ All other signal numbers you pass to target_signal_from_host will end up as TARGET_SIGNAL_UNKNOWN, due to the bunch of #ifdef SIGFOO bits in common/signals. Obviously, in most cases, this translation will be wrong. But the point to be taken is, target_signal_from_host _always_ translates the signal number passed as argument as if it was a host signal number, no matter what the target really is. -- Pedro Alves