From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9081 invoked by alias); 8 Dec 2005 20:38:34 -0000 Received: (qmail 9068 invoked by uid 22791); 8 Dec 2005 20:38:33 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 08 Dec 2005 20:38:32 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id jB8KcVmO029684 for ; Thu, 8 Dec 2005 15:38:31 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id jB8KcUV05362 for ; Thu, 8 Dec 2005 15:38:30 -0500 Received: from localhost.localdomain (vpn50-83.rdu.redhat.com [172.16.50.83]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id jB8KcUGg007691 for ; Thu, 8 Dec 2005 15:38:30 -0500 Received: from ironwood.lan (ironwood.lan [192.168.64.8]) by localhost.localdomain (8.12.11/8.12.10) with ESMTP id jB8KcOQT008533 for ; Thu, 8 Dec 2005 13:38:25 -0700 Date: Fri, 09 Dec 2005 11:09:00 -0000 From: Kevin Buettner To: gdb-patches@sources.redhat.com Subject: Re: [linux] Always ignore restart/cancellation signals Message-ID: <20051208133824.24b4c680@ironwood.lan> In-Reply-To: <200512081950.jB8Jo9im029464@elgar.sibelius.xs4all.nl> References: <20051208142420.GA21882@nevyn.them.org> <200512081950.jB8Jo9im029464@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2005-12/txt/msg00158.txt.bz2 On Thu, 8 Dec 2005 20:50:09 +0100 (CET) Mark Kettenis wrote: > > Date: Thu, 8 Dec 2005 09:24:20 -0500 > > From: Daniel Jacobowitz > > > > The comment is fairly self-explanatory. I guess I've always debugged > > failing cancellation tests with gdbserver, which hardwires these values > > already... > > > > Any objections? > > Hmm, I thought symbols starting with __ were "reserved by the > implemntation" and should not be used by user space programs. For the symbols in question, the header file, , says: /* These are the hard limits of the kernel. These values should not be used directly at user level. */ #define __SIGRTMIN 32 #define __SIGRTMAX (_NSIG - 1) So the comment supports your claim. The only alternative that I can think of is to hardcode the constant (32, in this case) into the GDB sources. Of these two approaches, I'd prefer to use __ symbol from the system headers. I do think that we ought to check for its existence first though. Kevin