public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Cc: gcc-patches@gcc.gnu.org, jason@redhat.com
Subject: Re: [PATCH] Refactor section/label init for early LTO debug
Date: Tue, 27 Sep 2016 10:41:00 -0000	[thread overview]
Message-ID: <alpine.LSU.2.11.1609271227570.26629@t29.fhfr.qr> (raw)
In-Reply-To: <yddeg45y7gh.fsf@CeBiTec.Uni-Bielefeld.DE>

On Tue, 27 Sep 2016, Rainer Orth wrote:

> Hi Richard,
> 
> > The following patch ports a refactoring of section/label in it from
> > the early LTO debug work to trunk.  For early LTO debug we need to
> > be able to emit two sets of debug infos into two sets of different
> > sections - early LTO into .gnu.debuglto_ prefixed sections and
> > regular (early + late) debug for the FAT part of the object.
> >
> > Thus this preparation splits out the section and label generation
> > from dwarf2out_init moving the text section related stuff to 
> > dwarf2out_assembly_start and the rest to a new function
> > init_sections_and_labels which is now called only before we start
> > outputting dwarf (in dwarf2out_finish).  It also removes some
> > dwarf_split_debug_info checks from the macro section name defines
> > (in the end I'll have up to four variants - regular, regular LTO,
> > DWO, DWO LTO).
> >
> > And it removes an unused function.
> >
> > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.  I've
> > also bootstrapped with -O2 -g3 to exercise the .debug_macro path.
> >
> > Ok?
> >
> > Just noticed that DEBUG_STR_OFFSETS_SECTION needs similar massaging
> > for its dwarf_split_debug_info condition - will followup as obvious
> > if this one is approved.
> 
> this patch introduced many pch assembly comparison failures on Solaris
> (both sparc and x86, 32 and 64-bit, /bin/as only), like
> 
> FAIL: gcc.dg/pch/common-1.c   -O3 -g  assembly comparison
> FAIL: gcc.dg/pch/common-1.c  -O0 -g assembly comparison
> 
> gcc.log shows this diff:
> 
> <       .long   .Letext0
> >       .long
> 
> While the .Letext0 label is still in the assembly output, it isn't
> referenced inside .debug_line, as can be seen in the diff.

Can you check if moving

static void
dwarf2out_assembly_start (void)
{
#ifndef DWARF2_LINENO_DEBUGGING_INFO
  ASM_GENERATE_INTERNAL_LABEL (text_section_label, TEXT_SECTION_LABEL, 0);
  ASM_GENERATE_INTERNAL_LABEL (text_end_label, TEXT_END_LABEL, 0);
  ASM_GENERATE_INTERNAL_LABEL (cold_text_section_label,
                               COLD_TEXT_SECTION_LABEL, 0);
  ASM_GENERATE_INTERNAL_LABEL (cold_end_label, COLD_END_LABEL, 0);

  switch_to_section (text_section);
  ASM_OUTPUT_LABEL (asm_out_file, text_section_label);
#endif

back to dwarf2out_init helps?  Ah!  Does

Index: gcc/dwarf2out.c
===================================================================
--- gcc/dwarf2out.c     (revision 240521)
+++ gcc/dwarf2out.c     (working copy)
@@ -25657,14 +25687,6 @@ dwarf2out_init (const char *filename ATT
     vec_alloc (macinfo_table, 64);
 #endif
 
-  /* Make sure the line number table for .text always exists.  */
-  text_section_line_info = new_line_info_table ();
-  text_section_line_info->end_label = text_end_label;
-
-#ifdef DWARF2_LINENO_DEBUGGING_INFO
-  cur_line_info_table = text_section_line_info;
-#endif
-
   /* If front-ends already registered a main translation unit but we were 
not
      ready to perform the association, do this now.  */
   if (main_translation_unit != NULL_TREE)
@@ -25688,6 +25710,14 @@ dwarf2out_assembly_start (void)
   ASM_OUTPUT_LABEL (asm_out_file, text_section_label);
 #endif
 
+  /* Make sure the line number table for .text always exists.  */
+  text_section_line_info = new_line_info_table ();
+  text_section_line_info->end_label = text_end_label;
+
+#ifdef DWARF2_LINENO_DEBUGGING_INFO
+  cur_line_info_table = text_section_line_info;
+#endif
+
   if (HAVE_GAS_CFI_SECTIONS_DIRECTIVE
       && dwarf2out_do_cfi_asm ()
       && (!(flag_unwind_tables || flag_exceptions)


fix it?  Ok if it passes testing for you.

Thanks,
Richard.

  reply	other threads:[~2016-09-27 10:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-21 13:34 Richard Biener
2016-09-23 19:37 ` Jason Merrill
2016-09-27 10:23 ` Rainer Orth
2016-09-27 10:41   ` Richard Biener [this message]
2016-09-27 10:55     ` Rainer Orth
2016-09-28  8:04       ` Richard Biener
2016-09-28  8:37         ` Richard Biener
2016-09-28  9:51     ` Un-break dwarf2out for DWARF2_LINENO_DEBUGGING_INFO configurations (was: [PATCH] Refactor section/label init for early LTO debug) Thomas Schwinge
2016-09-28 10:00       ` Richard Biener
2016-10-12 13:15         ` Thomas Schwinge
2016-09-27 10:24 [PATCH] Refactor section/label init for early LTO debug Dominique d'Humières

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=alpine.LSU.2.11.1609271227570.26629@t29.fhfr.qr \
    --to=rguenther@suse.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=ro@CeBiTec.Uni-Bielefeld.DE \
    /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).