public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Eric Botcazou <ebotcazou@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r12-2927] Disable GNAT encodings by default Date: Mon, 16 Aug 2021 10:16:19 +0000 (GMT) [thread overview] Message-ID: <20210816101619.9295F384801C@sourceware.org> (raw) https://gcc.gnu.org/g:29020d0527512ae0444ad32b1461b7f8526e7427 commit r12-2927-g29020d0527512ae0444ad32b1461b7f8526e7427 Author: Eric Botcazou <ebotcazou@gcc.gnu.org> Date: Mon Aug 16 12:14:12 2021 +0200 Disable GNAT encodings by default Given the latest work in the compiler and debugger, we no longer need to use most GNAT-specific encodings in the debug info generated for an Ada program, so the attached patch disables them, except with -fgnat-encodings=all. gcc/ * dwarf2out.c (add_data_member_location_attribute): Use GNAT encodings only when -fgnat-encodings=all is specified. (add_bound_info): Likewise. (add_byte_size_attribute): Likewise. (gen_member_die): Likewise. Diff: --- gcc/dwarf2out.c | 32 +++++++++++++++----------------- 1 file changed, 15 insertions(+), 17 deletions(-) diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c index b91a9b5abaa..4bcd3313fee 100644 --- a/gcc/dwarf2out.c +++ b/gcc/dwarf2out.c @@ -19915,22 +19915,23 @@ add_data_member_location_attribute (dw_die_ref die, { loc_descr = field_byte_offset (decl, ctx, &offset); - /* If loc_descr is available then we know the field offset is dynamic. - However, GDB does not handle dynamic field offsets very well at the - moment. */ - if (loc_descr != NULL && gnat_encodings != DWARF_GNAT_ENCODINGS_MINIMAL) + if (!loc_descr) + ; + + /* If loc_descr is available, then we know the offset is dynamic. */ + else if (gnat_encodings == DWARF_GNAT_ENCODINGS_ALL) { loc_descr = NULL; offset = 0; } - /* Data member location evalutation starts with the base address on the + /* Data member location evaluation starts with the base address on the stack. Compute the field offset and add it to this base address. */ - else if (loc_descr != NULL) + else add_loc_descr (&loc_descr, new_loc_descr (DW_OP_plus, 0, 0)); } - if (! loc_descr) + if (!loc_descr) { /* While DW_AT_data_bit_offset has been added already in DWARF4, e.g. GDB only added support to it in November 2016. For DWARF5 @@ -21389,12 +21390,9 @@ add_bound_info (dw_die_ref subrange_die, enum dwarf_attribute bound_attr, /* FALLTHRU */ default: - /* Because of the complex interaction there can be with other GNAT - encodings, GDB isn't ready yet to handle proper DWARF description - for self-referencial subrange bounds: let GNAT encodings do the - magic in such a case. */ + /* Let GNAT encodings do the magic for self-referential bounds. */ if (is_ada () - && gnat_encodings != DWARF_GNAT_ENCODINGS_MINIMAL + && gnat_encodings == DWARF_GNAT_ENCODINGS_ALL && contains_placeholder_p (bound)) return; @@ -21566,7 +21564,7 @@ add_byte_size_attribute (dw_die_ref die, tree tree_node) /* Support for dynamically-sized objects was introduced in DWARF3. */ else if (TYPE_P (tree_node) && (dwarf_version >= 3 || !dwarf_strict) - && gnat_encodings == DWARF_GNAT_ENCODINGS_MINIMAL) + && gnat_encodings != DWARF_GNAT_ENCODINGS_ALL) { struct loc_descr_context ctx = { const_cast<tree> (tree_node), /* context_type */ @@ -25629,11 +25627,11 @@ gen_member_die (tree type, dw_die_ref context_die) splice_child_die (context_die, child); } - /* Do not generate standard DWARF for variant parts if we are generating - the corresponding GNAT encodings: DIEs generated for both would - conflict in our mappings. */ + /* Do not generate DWARF for variant parts if we are generating the + corresponding GNAT encodings: DIEs generated for the two schemes + would conflict in our mappings. */ else if (is_variant_part (member) - && gnat_encodings == DWARF_GNAT_ENCODINGS_MINIMAL) + && gnat_encodings != DWARF_GNAT_ENCODINGS_ALL) { vlr_ctx.variant_part_offset = byte_position (member); gen_variant_part (member, &vlr_ctx, context_die);
reply other threads:[~2021-08-16 10:16 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20210816101619.9295F384801C@sourceware.org \ --to=ebotcazou@gcc.gnu.org \ --cc=gcc-cvs@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: linkBe 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).