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)
next prev parent 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