From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Ken Werner <ken@linux.vnet.ibm.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch] const array types
Date: Fri, 24 Sep 2010 04:50:00 -0000 [thread overview]
Message-ID: <20100923223709.GA25145@host1.dyn.jankratochvil.net> (raw)
In-Reply-To: <201009151920.37105.ken@linux.vnet.ibm.com>
On Wed, 15 Sep 2010 19:20:37 +0200, Ken Werner wrote:
> The attached patch changes the dwarf parsing of const types. In case the const
> qualifier is applied to an array type, the element type is so qualified, not the
> array type. Comments are welcome.
I have filed now http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45765 as
I believe it could be fixed more at the DWARF producer side.
It is questionable whether it gets accepted and fixed by GCC and whether you
would like it then fixed in GDB even for older GCCs and non-GCC compilers.
I believe besides TYPE_CODE_ARRAY the same logic should be applied even to all
the fields of TYPE_CODE_STRUCT and TYPE_CODE_UNION (excluding the static
fields). While ISO C99 does not say so (or does?) GCC behaves correctly:
const struct { int x; } b1;
__typeof__ (b1.x) b2;
(gdb) ptype b1.x
type = int
^^^ = The GDB (and possibly even GCC) bug.
(gdb) ptype b2
type = const int
^^^^^^^^^ GCC is aware the element is in fact `const'.
I would find this patch OK even if it fixes only the TYPE_CODE_ARRAY.
> + while (TYPE_CODE (TYPE_TARGET_TYPE (inner_array)) == TYPE_CODE_ARRAY)
The type can be opaque and TYPE_TARGET_TYPE is then NULL. Opaque type should
not be possible to be produced for an array element but some `error' call
would be nice there.
> + make_cv_type (1, TYPE_VOLATILE (el_type), el_type, 0);
^ NULL?
I would find NULL for a pointer parameter more readable.
Thanks,
Jan
next prev parent reply other threads:[~2010-09-23 22:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-15 19:32 Ken Werner
2010-09-24 4:50 ` Jan Kratochvil [this message]
2010-09-24 15:38 ` Jan Kratochvil
2010-09-24 16:27 ` Joel Brobecker
2010-09-24 16:40 ` Pedro Alves
2010-09-24 23:00 ` Joel Brobecker
2010-09-24 18:36 ` Ken Werner
2010-10-05 18:25 ` Ulrich Weigand
2010-10-05 18:43 ` Joel Brobecker
2010-10-06 15:38 ` Ken Werner
2010-10-06 15:55 ` Ulrich Weigand
2010-10-06 16:18 ` Ken Werner
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=20100923223709.GA25145@host1.dyn.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=ken@linux.vnet.ibm.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