From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1544 invoked by alias); 2 Sep 2010 15:39:40 -0000 Received: (qmail 1536 invoked by uid 22791); 2 Sep 2010 15:39:39 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 02 Sep 2010 15:39:35 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 9D8A52BACA7; Thu, 2 Sep 2010 11:39:33 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iClhTzURO4NO; Thu, 2 Sep 2010 11:39:33 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 2E2F02BAC86; Thu, 2 Sep 2010 11:39:33 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 10943F599F; Thu, 2 Sep 2010 17:39:23 +0200 (CEST) Date: Thu, 02 Sep 2010 16:02:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: gdb-patches@sourceware.org, Daniel Jacobowitz , Jan Kratochvil , Eli Zaretskii , Mark Kettenis Subject: Re: [patch 1/9]#2 Rename `enum target_signal' to target_signal_t Message-ID: <20100902153923.GN2986@adacore.com> References: <20100901200621.GA11085@caradoc.them.org> <201009012108.56984.pedro@codesourcery.com> <201009020254.47745.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201009020254.47745.pedro@codesourcery.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2010-09/txt/msg00097.txt.bz2 > Okay, upon popular request, I spend a bit this evening (well, night) > actually going ahead with that idea, while trying to not make > it much harder to debug, even without a pretty printer... > > The main change compared to what I suggested before, is to > not make the object empty as quoted above, but actually give it > some fields: > > struct target_signal_o > { > int number; > const char *name; > const char *string; > }; I like this approach! It's really nice to have all the information all in one place, for starters, and I wonder if we might want to do the same for Eg the ABI enumeration. The number of times I got bitten because I added one enumeration and forgot to update the associated array (not that we do it often enough that it mike make sense, it was just the example that came to mind). And I don't think that this is incompatible with Jan's initial goal of having a structure with signal and siginfo data. I admit I only glanced at this part of the discussion, but if we ever change our mind again, and determine that it is necessary to pass the siginfo_t data together with the signal, couldn't we just create a new struct that holds both, a la struct symtab_and_line? -- Joel