From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9344 invoked by alias); 4 Jun 2012 15:49:48 -0000 Received: (qmail 9316 invoked by uid 22791); 4 Jun 2012 15:49:44 -0000 X-SWARE-Spam-Status: No, hits=-7.5 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; Mon, 04 Jun 2012 15:49:27 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q54FnNmo000757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Jun 2012 11:49:23 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q54FnLST014484; Mon, 4 Jun 2012 11:49:22 -0400 Message-ID: <4FCCD900.3040102@redhat.com> Date: Mon, 04 Jun 2012 15:49: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: [PATCH] MIPS Linux signals References: <4FC9244F.1080704@eagerm.com> <4FC92EF9.3080804@eagerm.com> In-Reply-To: <4FC92EF9.3080804@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-06/txt/msg00083.txt.bz2 On 06/01/2012 10:07 PM, Michael Eager wrote: >>> #if defined (REALTIME_LO) >> >> Is this #ifdef needed? How about you rewrite this block using >> MIPS-specific definitions (MIPS_SIGRTMIN, etc.)? Please avoid hardcoded >> magic numbers too -- e.g. what are the magic values 32 and 33 below and >> how do they correlate to MIPS_SIGRTMIN, etc.? I can't get it from the >> change below. Should they be made relative to MIPS_SIGRTMIN perhaps? >> Are the values GDB_SIGNAL_REALTIME_* expand to not in order? > > This code is copied from signals.c. I don't really want to re-design > the logic since I don't have a straight-forward way to test the code. > > I'll recast this in terms of MIPS_SIGRTMIN, but all of your questions > can be addressed to the code in signals.c. I didn't find it clear, either. The whole point of gdb_signal_from_target is to be host independent. common/signals.c is all about host signal mapping. REALTIME_LO is either defined in the native header files in gdb/config/ (the nm-*.h files), or, if not defined there, common/signals.c does: #ifndef REALTIME_LO # if defined(__SIGRTMIN) # define REALTIME_LO __SIGRTMIN # define REALTIME_HI (__SIGRTMAX + 1) # elif defined(SIGRTMIN) # define REALTIME_LO SIGRTMIN # define REALTIME_HI (SIGRTMAX + 1) # endif #endif So that '#if defined (REALTIME_LO)' is really wrong for the gdbarch hook. The only nm header that defines REALTIME_LO presently, making the config/signals.c #ifndef be bypassed, is config/nm-nto.h: /* Setup the valid realtime signal range. */ #define REALTIME_LO 41 #define REALTIME_HI 56 So only when you build GDB hosted for QNX NTO would you see that new REALTIME_LO block in the mips tdep file be compiled... On all other hosts, including native GNU/Linux MIPS, you'd miss the conversions for all the realtime signals. I'm doing adding a few more comments to the gdbarch hook, plus doing a code change (that doesn't affect your patch) that hopefully makes things a bit clearer. -- Pedro Alves