From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12941 invoked by alias); 22 May 2012 19:32:12 -0000 Received: (qmail 12928 invoked by uid 22791); 22 May 2012 19:32:11 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from shell4.bayarea.net (HELO shell4.bayarea.net) (209.128.82.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 22 May 2012 19:31:58 +0000 Received: (qmail 3830 invoked from network); 22 May 2012 12:31:58 -0700 Received: from c-76-102-3-160.hsd1.ca.comcast.net (HELO redwood.eagercon.com) (76.102.3.160) by shell4.bayarea.net with SMTP; 22 May 2012 12:31:57 -0700 Message-ID: <4FBBE9AC.5030200@eagerm.com> Date: Tue, 22 May 2012 19:32:00 -0000 From: Michael Eager User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Pedro Alves 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> <4FBBDB61.7070002@redhat.com> In-Reply-To: <4FBBDB61.7070002@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00846.txt.bz2 On 05/22/2012 11:30 AM, Pedro Alves wrote: > 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. I think the point is that a target signal number should always be treated as if it were from a target, never that it was from the host. All the #ifdefs checking if the host has this signal or that is confusing. The only thing that seems relevant to me is whether the target has these signals. If it happens that target==host, then these happen to be equivalent. But maintaining a clear target abstraction is a benefit. -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077