public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <aoliva@redhat.com>
To: gcc-patches@gcc.gnu.org
Subject: bootstrap-debug-lean + flags in producer vs compare
Date: Fri, 06 Oct 2017 01:15:00 -0000	[thread overview]
Message-ID: <or1smh5b6i.fsf@lxoliva.fsfla.org> (raw)

Unlike bootstrap-debug, bootstrap-debug-lean used to pass compare using
the traditional compare command, because it compiled both stage2 and
stage3 with options that used to generate identical output
(-fcompare-debug= in stage2 vs -fcompare-debug in stage3).

Since we started adding relevant command-line flags to DW_AT_producer,
this is no longer the case, and stages 2 and 3 object files that differ
in nothing but the DW_AT_producer strings.


-fcompare-debug is short for -fcompare-debug=-gtoggle, so stage3
compiles twice, once with the normal options, once with toggled -g, to
then compare the temporary final dumps.  When enabled, both compilations
get from the driver an additional -frandom-seed flag (if none is given
explicitly).

-fcompare-debug= is short for -fno-compare-debug, disabling the second
compilation.


The difference between the DW_AT_producer lines are the different
-fcompare-debug flags, and the presence of the -frandom-seed flag in the
stage3 compilation.

It should be easy and sensible enough to filter the -fcompare-debug
flags out of the DW_AT_producer string.  This option should never affect
the compilation output, it just determines whether or not to perform an
additional compilation that should produce the same executable output.

However, doing that but that won't get us rid of the -frandom-seed
option.  We could drop -frandom-seed from the DW_AT_producer output too,
but I don't think we should do that when the option is given by the
user, rather than implicitly introduced by -fcompare-debug.  We could
introduce an option that causes the subsequent option to be omitted from
the DW_AT_producer string, and arrange for -fcompare-debug to issue that
option before the -frandom-seed option it issues.  The problem with this
approach is that I can't decide whether it's an option prone to abuse,
or one that can have other legitimate uses.


Another approach to fix (or rather hide) this failure mode is to allow
the debug information to differ under bootstrap-debug-lean, by using the
same compare-debug script we use for bootstrap-debug.  The first
patchlet below does just that.  The second drops -fcompare-debug from
DW_AT_producer.  A third (not written yet :-) might somehow deal with
the -frandom-seed added by -fcompare-debug, and either the first or the
others would be posted as a single, fully tested patch, once we decide
how we want to deal with -frandom-seed.


Thoughts?  Thanks in advance,


diff --git a/config/bootstrap-debug-lean.mk b/config/bootstrap-debug-lean.mk
index e215280..5f2db80 100644
--- a/config/bootstrap-debug-lean.mk
+++ b/config/bootstrap-debug-lean.mk
@@ -9,3 +9,4 @@
 
 STAGE2_CFLAGS += -fcompare-debug=
 STAGE3_CFLAGS += -fcompare-debug
+do-compare = $(SHELL) $(srcdir)/contrib/compare-debug $$f1 $$f2


diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index ed7a85a..f077b35 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -23846,6 +23846,7 @@ gen_producer_string (void)
       case OPT_fltrans_output_list_:
       case OPT_fresolution_:
       case OPT_fdebug_prefix_map_:
+      case OPT_fcompare_debug:
 	/* Ignore these.  */
 	continue;
       default:


-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

             reply	other threads:[~2017-10-06  1:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-06  1:15 Alexandre Oliva [this message]
2017-10-31  1:20 ` Jeff Law
2017-11-11  1:00   ` Alexandre Oliva
2017-11-13 10:16     ` Richard Biener

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=or1smh5b6i.fsf@lxoliva.fsfla.org \
    --to=aoliva@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).