From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17547 invoked by alias); 9 Jul 2002 11:06:00 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 17533 invoked by uid 71); 9 Jul 2002 11:06:00 -0000 Date: Tue, 09 Jul 2002 04:06:00 -0000 Message-ID: <20020709110600.17532.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Franz Sirl Subject: Re: debug/7241: DWARF encoding for "char" incorrect in gcc Reply-To: Franz Sirl X-SW-Source: 2002-07/txt/msg00261.txt.bz2 List-Id: The following reply was made to PR debug/7241; it has been noted by GNATS. From: Franz Sirl To: jcownie@etnus.com Cc: gcc-gnats@gcc.gnu.org,gcc-bugs@gcc.gnu.org Subject: Re: debug/7241: DWARF encoding for "char" incorrect in gcc Date: Tue, 09 Jul 2002 13:04:25 +0200 At 12:01 09.07.2002, jcownie@etnus.com wrote: > >Number: 7241 > >Category: debug > >Synopsis: DWARF encoding for "char" incorrect in gcc > >Confidential: no > >Severity: serious > >Priority: medium > >Responsible: unassigned > >State: open > >Class: sw-bug > >Submitter-Id: net > >Arrival-Date: Tue Jul 09 03:06:00 PDT 2002 > >Closed-Date: > >Last-Modified: > >Originator: James Cownie > >Release: 3.1 > >Organization: >Etnus LLC > >Environment: >System: Linux pc4 2.4.18 #1 Tue Apr 2 10:17:01 BST 2002 i686 unknown >Architecture: i686 >host: i686-pc-linux-gnu >build: i686-pc-linux-gnu >target: i686-pc-linux-gnu >configured with: /home1/GNU/gcc-3.1/configure > > >Description: >The DWARF emitted for a "char" variable is incorrect from gcc, but >correct from g++. > >Consider this code >---- const_strings.c --------- >typedef struct >{ > const char * name; > int value; >} named_value; > >int main (int argc, char ** argv) >{ > named_value v; > const char * zero = "zero"; > > v.name = "one"; > v.value = 1; > > v.value++; >} >------------------------------- >jcownie@pc4: gcc31 -v -g -c const_strings.c >Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs >Configured with: /home1/GNU/gcc-3.1/configure >Thread model: single >gcc version 3.1 > /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/cc1 -lang-c -v -iprefix > /home1/jim/bin/Linux-i686/../lib/gcc-lib/i686-pc-linux-gnu/3.1/ > -D__GNUC__=3 -D__GNUC_MINOR__=1 -D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix > -D__gnu_linux__ -Dlinux -D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__ > -D__unix -D__linux -Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1 > -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i686__ > -D__tune_pentiumpro__ const_strings.c -quiet -dumpbase const_strings.c -g > -version -o /tmp/ccStmXSo.s >GNU CPP version 3.1 (cpplib) (i386 Linux/ELF) >GNU C version 3.1 (i686-pc-linux-gnu) > compiled by GNU C version 3.1. >ignoring nonexistent directory >"/home1/jim/bin/Linux-i686/../lib/gcc-lib/i686-pc-linux-gnu/3.1/include" >ignoring nonexistent directory >"/home1/jim/bin/Linux-i686/../lib/gcc-lib/i686-pc-linux-gnu/3.1/../../../../i686-pc-linux-gnu/include" >ignoring nonexistent directory "NONE/include" >ignoring nonexistent directory "/usr/local/i686-pc-linux-gnu/include" >#include "..." search starts here: >#include <...> search starts here: > /usr/local/include > /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/include > /usr/include >End of search list. > as --traditional-format -V -Qy -o const_strings.o /tmp/ccStmXSo.s >GNU assembler version 2.12 (i686-pc-linux-gnu) using BFD version 2.12 > >If we dump out the DWARF info with readelf -wi we see that the >definition of the base type "char" is > > <1>: Abbrev Number: 6 (DW_TAG_base_type) > DW_AT_name : char > DW_AT_byte_size : 1 > DW_AT_encoding : 5 (signed) > >Which (see page 62 of the DWARF 3 document) defines it as a signed >binary integer of size one byte, _NOT_ a signed character (which would >be encoding 6). > >If we do the same thing with g++, we get > <1>: Abbrev Number: 5 (DW_TAG_base_type) > DW_AT_name : char > DW_AT_byte_size : 1 > DW_AT_encoding : 6 (signed char) > >which is correct. Hmm, I would rather think g++ is the wrong one here. IIRC in C++ (C too?) "char"/"signed char"/"unsigned char" are actually 3 distinct types and thus encoding 6 should have only be used if you would have explicitly written "signed char" in your example, or? Franz.