From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25479 invoked by alias); 22 May 2012 22:06:24 -0000 Received: (qmail 25466 invoked by uid 22791); 22 May 2012 22:06: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 22:06:08 +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 q4MM64ZD009553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 May 2012 18:06:04 -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 q4MM62Mu015957; Tue, 22 May 2012 18:06:03 -0400 Message-ID: <4FBC0DCA.2060706@redhat.com> Date: Tue, 22 May 2012 22:06: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> <4FBBDB61.7070002@redhat.com> <4FBBE9AC.5030200@eagerm.com> In-Reply-To: <4FBBE9AC.5030200@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/msg00852.txt.bz2 On 05/22/2012 08:31 PM, Michael Eager wrote: >> >> 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. The discussion on the table is not about what should or not should be design wise. The discussion is about the confusing target_signal_from_host method name. I've given ample explanation of why that should have "host" in its name. If we should eliminate that function and instead provide gdbarch mappings for all targets or not is a different discussion. The fact remains that target_signal_from_host exists, and is widely used. I'd very much like to retain "host" in its name to remind the reader that while it exists, its implementation really is just a mapping from the host signals. I'm now pretty much done with repeating the arguments. > target signal number should always be treated as if it were from a target, That requires GDB hardcoding signal mappings, and that's what the gdbarch hook is for. And that's why I proposed renaming it: http://sourceware.org/ml/gdb-patches/2012-05/msg00839.html -- Pedro Alves