From: Aldy Hernandez <aldyh@redhat.com>
To: gcc-patches <gcc-patches@gcc.gnu.org>
Subject: [debug-early] handle objects containing variable-length members
Date: Fri, 10 Apr 2015 18:25:00 -0000 [thread overview]
Message-ID: <55281589.9010209@redhat.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]
The attached patch handles late dwarf annotations to objects containing
variable-length members. It fixes the following regressions in the gdb
testsuite:
> FAIL: gdb.base/vla-datatypes.exp: print vla_struct_object
> FAIL: gdb.base/vla-datatypes.exp: print vla_union_object
> FAIL: gdb.base/vla-datatypes.exp: ptype vla_struct_object
> FAIL: gdb.base/vla-datatypes.exp: ptype vla_union_object
> FAIL: gdb.base/vla-datatypes.exp: size of vla_struct_object
> FAIL: gdb.base/vla-datatypes.exp: size of vla_union_object
I am not convinced this is the last patch to variable-length variables,
so it may require further refining, but it does get us down to ZERO gdb
regressions which is A Good Thing (TM).
The only differences I see for trunk and the debug-early branch wrt gdb
regressions are:
< KFAIL: gdb.cp/oranking.exp: p foo4(&a) (PRMS: gdb/12098)
---
> KPASS: gdb.cp/oranking.exp: p foo4(&a) (PRMS gdb/12098)
20065c20065
< KFAIL: gdb.cp/oranking.exp: p foo101("abc") (PRMS: gdb/12098)
---
> KPASS: gdb.cp/oranking.exp: p foo101("abc") (PRMS gdb/12098)
28222c28222
Plus some noise regarding threads.
I don't know what KFAIL/KPASS are, having lived in GCC land too long,
but I will take a look at those next.
Committed to branch.
Aldy
[-- Attachment #2: curr --]
[-- Type: text/plain, Size: 2607 bytes --]
commit b7cc4054654591a53e7dcc6a33f1ec35a3c5a7f9
Author: Aldy Hernandez <aldyh@redhat.com>
Date: Fri Apr 10 11:16:46 2015 -0700
Handle late dwarf annotations to objects containing variable-length
members.
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 1928846..0976415 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -20470,6 +20470,16 @@ static void
gen_struct_or_union_type_die (tree type, dw_die_ref context_die,
enum debug_info_usage usage)
{
+ /* Fill in the size of variable lengthed fields in late dwarf. */
+ if (TREE_ASM_WRITTEN (type)
+ && !early_dwarf_dumping)
+ {
+ tree member;
+ for (member = TYPE_FIELDS (type); member; member = DECL_CHAIN (member))
+ fill_variable_array_bounds (TREE_TYPE (member));
+ return;
+ }
+
dw_die_ref type_die = lookup_type_die (type);
dw_die_ref scope_die = 0;
int nested = 0;
@@ -20676,13 +20686,15 @@ gen_tagged_type_die (tree type,
|| !is_tagged_type (type))
return;
+ if (TREE_ASM_WRITTEN (type))
+ need_pop = 0;
/* If this is a nested type whose containing class hasn't been written
out yet, writing it out will cover this one, too. This does not apply
to instantiations of member class templates; they need to be added to
the containing class as they are generated. FIXME: This hurts the
idea of combining type decls from multiple TUs, since we can't predict
what set of template instantiations we'll get. */
- if (TYPE_CONTEXT (type)
+ else if (TYPE_CONTEXT (type)
&& AGGREGATE_TYPE_P (TYPE_CONTEXT (type))
&& ! TREE_ASM_WRITTEN (TYPE_CONTEXT (type)))
{
@@ -20810,11 +20822,14 @@ gen_type_die_with_usage (tree type, dw_die_ref context_die,
if (TREE_ASM_WRITTEN (type))
{
- /* Variabled-lengthed types may be incomplete even if
+ /* Variable-length types may be incomplete even if
TREE_ASM_WRITTEN. For such types, fall through to
gen_array_type_die() and possibly fill in
DW_AT_{upper,lower}_bound attributes. */
- if (TREE_CODE (type) != ARRAY_TYPE
+ if ((TREE_CODE (type) != ARRAY_TYPE
+ && TREE_CODE (type) != RECORD_TYPE
+ && TREE_CODE (type) != UNION_TYPE
+ && TREE_CODE (type) != QUAL_UNION_TYPE)
|| (TYPE_SIZE (type)
&& TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST))
return;
@@ -20870,9 +20885,6 @@ gen_type_die_with_usage (tree type, dw_die_ref context_die,
break;
case ARRAY_TYPE:
- gen_array_type_die (type, context_die);
- break;
-
case VECTOR_TYPE:
gen_array_type_die (type, context_die);
break;
next reply other threads:[~2015-04-10 18:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-10 18:25 Aldy Hernandez [this message]
2015-04-11 5:07 ` Mike Stump
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=55281589.9010209@redhat.com \
--to=aldyh@redhat.com \
--cc=gcc-patches@gcc.gnu.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).