Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
To: "'Pedro Alves'" <pedro@codesourcery.com>
Cc: <gdb-patches@sourceware.org>
Subject: RE: [RFA]dwarf reader:  Avoid complaint on const type
Date: Sun, 20 Jun 2010 22:39:00 -0000	[thread overview]
Message-ID: <005401cb10c9$7dbcfec0$7936fc40$@muller@ics-cnrs.unistra.fr> (raw)
In-Reply-To: <201006161708.41089.pedro@codesourcery.com>

Hi Pedro,

  I checked this a little, but it is still unclear to me:
gcc-3 only emits a DW_AT_type attribute, no DW_AT_name,
so there is no problem in that case.
  On gcc16, I do see the failure that you see,
but I rechecked my tests when I submitted, and there 
is no sigaltstack failure.
  I think that wehen I submitted the patch, I was supposing that
if the DW_TAG_volatile_type would have a name attribute,
it would only be to give the name of the newly defined type,
i.e. for a typedef.
  Apparently, GCC changed a reports the old "unmodified" type name.

  The patch below should fix this.


Pierre Muller

PS: 
gcc does not emit typedefs for volatile types:


>>>>Start of test-vol.c<<<<<<
enum level { MAIN, OUTER, INNER, LEAF, NR_LEVELS };

/* Levels completed flag.  */
typedef volatile enum level level2;
volatile enum level level = NR_LEVELS;

typedef volatile int  volint;

volint vol;

level2 test = OUTER;

int local ()
{
  typedef volatile enum level level;
  level loc;
  loc = INNER;
  return 0;
}

int
main ()
{
  vol = 5;
  level = MAIN;
  test = LEAF;
  local ();
  return 0;
}
>>>>Start of test-vol.c<<<<<<
gcc -gdwarf2 test-vol.c
results in an  executable with no information
about volint type.
(stabs info gives correct information)...
I have to add here that I hate the C way of describing typedefs:
(gdb) inf type myint
type int;
This is almost completely useless, especially when you do a 
(gdb) inf type
myint does not appear anywhere :(
 

Back to the patch itself:

ChangeLog entry:

2010-06-21  Pierre Muller  <muller@ics.u-strasbg.fr>

	* dwarf2read.c (process_die): Do not call new_symbol
	for DW_TAG_volatile_type and DW_TAG_const_type.
	(new_symbol): Do not add the name of DW_TAG_volatile_type 
	and DW_TAG_const_type to the symbol list.



Index: dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.400
diff -u -p -r1.400 dwarf2read.c
--- dwarf2read.c        17 Jun 2010 22:36:41 -0000      1.400
+++ dwarf2read.c        20 Jun 2010 21:57:23 -0000
@@ -3210,12 +3210,14 @@ process_die (struct die_info *die, struc
     case DW_TAG_base_type:
     case DW_TAG_subrange_type:
     case DW_TAG_typedef:
-    case DW_TAG_const_type:
-    case DW_TAG_volatile_type:
       /* Add a typedef symbol for the type definition, if it has a
          DW_AT_name.  */
       new_symbol (die, read_type_die (die, cu), cu);
       break;
+    case DW_TAG_const_type:
+    case DW_TAG_volatile_type:
+      read_type_die (die, cu);
+      break;
     case DW_TAG_common_block:
       read_common_block (die, cu);
       break;
@@ -8912,12 +8914,16 @@ new_symbol (struct die_info *die, struct
          break;
        case DW_TAG_base_type:
         case DW_TAG_subrange_type:
-        case DW_TAG_const_type:
-        case DW_TAG_volatile_type:
          SYMBOL_CLASS (sym) = LOC_TYPEDEF;
          SYMBOL_DOMAIN (sym) = VAR_DOMAIN;
          add_symbol_to_list (sym, cu->list_in_scope);
          break;
+        case DW_TAG_const_type:
+        case DW_TAG_volatile_type:
+         /* The name of the type given in the dwarf name atribute is the
+            name of the `normal' type and not a new type name, so
+            do not register this as a new type name.  */
+         break;
        case DW_TAG_enumerator:
          attr = dwarf2_attr (die, DW_AT_const_value, cu);
          if (attr)


  reply	other threads:[~2010-06-20 22:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <41597.7287375883$1274454923@news.gmane.org>
2010-05-21 17:20 ` Tom Tromey
2010-05-21 20:46   ` Pierre Muller
2010-06-16 16:08     ` Pedro Alves
2010-06-20 22:39       ` Pierre Muller [this message]
     [not found]       ` <3752333521215815628@unknownmsgid>
2010-06-28 20:27         ` Doug Evans
2010-06-29 13:09           ` Pierre Muller
2010-07-01 17:09             ` Pedro Alves
2010-07-01 17:13               ` Joel Brobecker
2010-07-21 17:16                 ` Pedro Alves
     [not found]           ` <29342.6726283089$1277816998@news.gmane.org>
2010-07-02 21:47             ` Tom Tromey
2010-05-21 15:31 Pierre Muller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='005401cb10c9$7dbcfec0$7936fc40$@muller@ics-cnrs.unistra.fr' \
    --to=pierre.muller@ics-cnrs.unistra.fr \
    --cc=gdb-patches@sourceware.org \
    --cc=pedro@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox