From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20912 invoked by alias); 7 Jan 2009 19:56:24 -0000 Received: (qmail 20899 invoked by uid 22791); 7 Jan 2009 19:56:23 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,KAM_MX,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 07 Jan 2009 19:56:19 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n07JuGgJ000974; Wed, 7 Jan 2009 14:56:17 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n07JuGjF031696; Wed, 7 Jan 2009 14:56:16 -0500 Received: from opsy.redhat.com (vpn-12-79.rdu.redhat.com [10.11.12.79]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n07JuFci006090; Wed, 7 Jan 2009 14:56:16 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id EC29150801F; Wed, 7 Jan 2009 12:56:13 -0700 (MST) To: "Sean D'Epagnier" Cc: gdb-patches@sourceware.org Subject: Re: [patch] add support for debugging fixed-point numbers References: From: Tom Tromey Reply-To: Tom Tromey Date: Wed, 07 Jan 2009 19:56:00 -0000 In-Reply-To: (Sean D'Epagnier's message of "Wed\, 31 Dec 2008 14\:45\:44 -0600") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2009-01/txt/msg00113.txt.bz2 >>>>> "Sean" == Sean D'Epagnier writes: Sean> Thanks so much for reviewing my patch. I am sorry for all the Sean> inconsistencies, I will do my best to correct them, more comments Sean> below. Oh, don't be sorry... the coding standard is just a little hurdle everybody has to get over when they first contribute, not a big deal. Tom> I am not really that familiar with the fixed-point extension to C. My Tom> understanding is that some of the types saturate -- but I didn't see Tom> any code here related to saturation. Am I missing something? Sean> If the type is _Sat, then it is a saturating type. I did not have any Sean> support for this, however there is currently no way for me to know if Sean> a variable is a saturating type (nothing in the dwarf format Sean> specifying it) So gdb might be inconsistent in the sense that if you Sean> add a number to a saturating variable ie: "p x+.5" and x saturates, Sean> then gdb won't know to saturate it, but unless we add more fields to Sean> dwarf specifying this. What do you suggest we do about this? At Sean> least you can examine saturating values correctly. This sounds like a Dwarf oversight to me. Perhaps we can either get something officially defined here (I don't know how to do that, though), or define a GNU extension. I think that, at least, this ought to be filed as a GCC bug, and maybe a GDB bug as well, once your patch goes in. IMO, the absence of this information should not block your patch. Sean> I also noticed what seems to be a quirk in gdb. Maybe you have some Sean> insight. If you launch gdb and type something like: Sean> (gdb) p ((unsigned _Accum)- 1) Sean> $7 = -1 Sean> (gdb) p ((unsigned int)- 1) Sean> $8 = 65535 [...] Offhand, I have no idea what is going on here, sorry. Sean> I'm not sure which is best, to try to add fixed-point support to stabs Sean> format too, or to make gdb read the types from the dwarf format in Sean> this case (or maybe both) I also have no idea about this :). I don't know anything about stabs, I'm afraid. Tom