public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: debug/7241: DWARF encoding for "char" incorrect in gcc
@ 2002-07-09  4:06 Franz Sirl
  0 siblings, 0 replies; 3+ messages in thread
From: Franz Sirl @ 2002-07-09  4:06 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR debug/7241; it has been noted by GNATS.

From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
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><a0>: 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><d7>: 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.
 


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: debug/7241: DWARF encoding for "char" incorrect in gcc
@ 2002-07-09  4:16 James Cownie
  0 siblings, 0 replies; 3+ messages in thread
From: James Cownie @ 2002-07-09  4:16 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR debug/7241; it has been noted by GNATS.

From: James Cownie <jcownie@etnus.com>
To: Franz Sirl <Franz.Sirl-kernel@lauterbach.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 12:12:20 +0100

 > 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?
 
 My point is not the issue of signedness, but that of "character"-ness.
 
 Gcc is emitting this as if it were int8_t (a single byte integer), and
 is not telling the debugger that the type should be displayed as
 holding a character.
 
 DWARF only has encodings for explicitly signed or explicitly unsigned
 objects. The fact that C has three different char types ("char",
 "signed char" and "unsigned char") is not expressible in DWARF, where
 the debugger needs to know what the underlying representation really
 is. Therefore in DWARF I would always expect that the C "char" type
 should be represented as either DW_ATE_signed_char or
 DW_ATE_unsigned_char, as appropriate.
 
 "char" should _not_ be represented as DW_ATE_signed or DW_ATE_unsigned,
 since those are _integer_ types, and the debugger will not attempt to
 display them as characters.
 
 -- Jim 
 
 James Cownie	<jcownie@etnus.com>
 Etnus, LLC.     +44 117 9071438
 http://www.etnus.com


^ permalink raw reply	[flat|nested] 3+ messages in thread

* debug/7241: DWARF encoding for "char" incorrect in gcc
@ 2002-07-09  3:06 jcownie
  0 siblings, 0 replies; 3+ messages in thread
From: jcownie @ 2002-07-09  3:06 UTC (permalink / raw)
  To: gcc-gnats


>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><a0>: 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><d7>: 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.

>How-To-Repeat:
As above.
>Fix:
	
>Release-Note:
>Audit-Trail:
>Unformatted:


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-07-09 11:16 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-07-09  4:06 debug/7241: DWARF encoding for "char" incorrect in gcc Franz Sirl
  -- strict thread matches above, loose matches on Subject: below --
2002-07-09  4:16 James Cownie
2002-07-09  3:06 jcownie

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).