From owner-freebsd-arch@FreeBSD.ORG Thu Jan 18 03:21:10 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5873E16A407 for ; Thu, 18 Jan 2007 03:21:10 +0000 (UTC) (envelope-from sbenabas@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id D2EA513C45B for ; Thu, 18 Jan 2007 03:21:09 +0000 (UTC) (envelope-from sbenabas@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so58520uge for ; Wed, 17 Jan 2007 19:21:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=fIu3/sA6tJVSN4zUBPA3ttKGbbwMtx4J2g05TkIum2hpWPHTSdzV0/KeaEOauQ5fKvR2gPp4Gp3Vmva72jdx7hcADP+p+zi4Bd92u5otW43goakn6khAsMkJBQ7nnte4inyhVSTzsDdLU9LqhEJ6OSPVuGjwfHIavHktOswZCek= Received: by 10.66.221.6 with SMTP id t6mr537814ugg.1169088977716; Wed, 17 Jan 2007 18:56:17 -0800 (PST) Received: by 10.67.101.20 with HTTP; Wed, 17 Jan 2007 18:56:17 -0800 (PST) Message-ID: <32d8477c0701171856i6f7c4cdy384ad2e10086a65f@mail.gmail.com> Date: Wed, 17 Jan 2007 21:56:17 -0500 From: "Siavosh Benabbas" To: freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: siginfo_t.si_code macro constants X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2007 03:21:10 -0000 Hi, I am trying to compile parted on freebsd and I came across this. It seems that many macro constants of POSIX that one should be able to check the value of siginfo_t.si_code in a 3 parameter signal handler (set by sigaction) are missing. These in particular include SEGV_MAPPER, SEGV_ACCERR, and many ILL_* constants the man page of sigaction mentions: "The code argument of the BSD-style handler and the si_code member of the info argument to a SA_SIGINFO handler contain a numeric code explaining the cause of the signal, usually one of the SI_... values from or codes specific to a signal, i.e., one of the FPE_... values for SIGFPE." But it doesn't specifically list the macro's available. According to the POSIX standard there should be some SEGV_* and ILL_* constants too. I searched in the archives and it seems that this was pointed out around a year ago. The mail in the archive also mentioned that siginfo_t.si_code actually gets populated but there is no constant to check this against. The following is from (a distribution of) linux's man page for sigaction describing some of the constants available on Linux: +-------------------------------------+ | SIGILL | +-----------+-------------------------+ |ILL_ILLOPC | illegal opcode | +-----------+-------------------------+ |ILL_ILLOPN | illegal operand | +-----------+-------------------------+ |ILL_ILLADR | illegal addressing mode | +-----------+-------------------------+ |ILL_ILLTRP | illegal trap | +-----------+-------------------------+ |ILL_PRVOPC | privileged opcode | +-----------+-------------------------+ |ILL_PRVREG | privileged register | +-----------+-------------------------+ |ILL_COPROC | coprocessor error | +-----------+-------------------------+ |ILL_BADSTK | internal stack error | +-----------+-------------------------+ .... +----------------------------------------------------+ | SIGSEGV | +------------+---------------------------------------+ |SEGV_MAPERR | address not mapped to object | +------------+---------------------------------------+ |SEGV_ACCERR | invalid permissions for mapped object | +------------+---------------------------------------+ .... Unfortunately I lack the expertise to implement any of these but I wanted to ask if anybody has a similar problem and/or is working on this. Thanks, Siavosh Benabbas