From: Daniel Jacobowitz <drow@false.org>
To: Gary Funck <gary@intrepid.com>
Cc: gdb@sourceware.org
Subject: Re: how to support C type qualifiers applied to arrays?
Date: Mon, 27 Nov 2006 23:10:00 -0000 [thread overview]
Message-ID: <20061127230948.GA19798@nevyn.them.org> (raw)
In-Reply-To: <200611272217.kARMHtw3023324@intrepid.intrepid.com>
On Mon, Nov 27, 2006 at 02:42:12PM -0800, Gary Funck wrote:
> Q: Is GCC generating an inaccurate DWARF 2 representation
> to describe a qualified array type, or is GDB not
> interpreting the DWARF 2 information correctly?
I will defer to experts on this but I believe GCC is incorrect.
In C there is no such thing as a "qualified array type". The array has
an element type (which can be c-v qualified) and a bound, and no
qualifiers of its own. But you can say "int x[const 1]". You can't
define variables of this type, but you can use them in function
declarations. I believe it means roughly "int *const x" within the
function; normally you can write:
int f(int x[1])
{
x[0] = 1;
x++;
return 0;
}
But this is invalid:
int f(int x[const 1])
{
x[0] = 1;
x++;
return 0;
}
So, by stuffing qualifiers on the outside, we lose the ability to
present that. But GCC emits debug info for those as int f(int *)
and int f(int * const) respectively, so it's irrelevant in practice.
We can assume the qualifiers belonged to the element type in GDB.
> We see that make_cv_type() is called to qualify 'base_type' as "const".
> Make_cv_type() does this by setting a flag bit in the 'instance_flags'
> field of base_type. In our example above, 'base_type' is an array type.
My first recommendation would be to have make_cv_type create a new
array type, with the qualified element type. However, doing this
without being excessively wasteful might require care - you couldn't
reuse main_type since the qualified array could not share main_type.
But the waste is acceptably small.
The alternative would be to have a function called to get the base type
of an array which did appropriate qualification at that point. The
easiest way to do it might be to make TYPE_TARGET_TYPE into an
appropriate function. Better than auditing the 465 or so calls.
The first is probably better. It should be done in gdbtypes.c, not
in the DWARF reader specifically.
I see that these are roughly the same two possibilities you offered :-)
I would do it at a different level than expression evaluation, though,
as you can see above, if I took the second option.
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2006-11-27 23:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-27 22:42 Gary Funck
2006-11-27 23:10 ` Daniel Jacobowitz [this message]
2006-11-27 23:30 ` Jim Blandy
2006-11-27 23:52 ` Daniel Jacobowitz
2006-11-27 23:45 ` Joseph S. Myers
2006-11-27 23:55 ` Daniel Jacobowitz
2006-12-14 20:22 ` Gary Funck
2006-12-15 22:36 ` Jim Blandy
2006-12-19 19:09 ` Gary Funck
2006-12-20 2:40 ` Gary Funck
2006-12-27 2:12 ` Jim Blandy
2007-01-01 22:16 ` Jim Wilson
2007-01-09 17:01 ` Gary Funck
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=20061127230948.GA19798@nevyn.them.org \
--to=drow@false.org \
--cc=gary@intrepid.com \
--cc=gdb@sourceware.org \
/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