From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23945 invoked by alias); 9 Mar 2012 17:00:26 -0000 Received: (qmail 23918 invoked by uid 22791); 9 Mar 2012 17:00:22 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,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; Fri, 09 Mar 2012 17:00:05 +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 q29GxqpE019973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Mar 2012 11:59:52 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q29GxoZ4012038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 9 Mar 2012 11:59:51 -0500 From: Tom Tromey To: Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: [RFA] ax-gdb: Do not treat enums and bools as integers. References: <1331240440-13559-1-git-send-email-brobecker@adacore.com> Date: Fri, 09 Mar 2012 17:00:00 -0000 In-Reply-To: <1331240440-13559-1-git-send-email-brobecker@adacore.com> (Joel Brobecker's message of "Thu, 8 Mar 2012 13:00:40 -0800") Message-ID: <874ntxlng9.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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-03/txt/msg00340.txt.bz2 >>>>> "Joel" == Joel Brobecker writes: Joel> But the reason why GDB decides to use a 32bit extension is because Joel> it overrides the symbol's type with a plain integer type in Joel> ax-gdb.c:gen_usual_unary... FWIW you can see the bug from C, if you make an enum type and then compile with -fshort-enums (which IIRC is the default for some targets). Then: (gdb) maintenance agent-eval e Scope: 0x400478 Reg mask: 00 0 const32 6293576 5 ref8 6 end Here the 'ref8' is correct -- 'e' is a 1-byte variable. But: (gdb) maintenance agent-eval e + 1 Scope: 0x400478 Reg mask: 00 0 const32 6293576 5 ref32 6 ext 32 8 const8 1 10 add 11 ext 32 13 end Whoops, how did that ref32 get there? Joel> * ax-gdb.c (gen_usual_unary): Remove special handling of Joel> enum and bool types. I think it is correct. Also, I think you can make a test case like this: enum EE { VALUE = 1 }; struct x { unsigned char before; enum EE e; unsigned char after; }; struct x global; int main () { } Compile with -fshort-enums. Then: (gdb) maint agent-eval global.e + 1 Scope: 0x400478 Reg mask: 00 0 const32 6293576 5 const8 1 7 add 8 ref32 9 ext 32 11 const8 1 13 add 14 ext 32 16 end So, I think you could provoke the wrong answer by setting 'after' to some non-zero value. Tom