public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* PATCH RFC: Add -fmerge-debug-strings option
@ 2007-11-17  5:42 Ian Lance Taylor
  2007-11-24 10:42 ` Mark Mitchell
  0 siblings, 1 reply; 3+ messages in thread
From: Ian Lance Taylor @ 2007-11-17  5:42 UTC (permalink / raw)
  To: gcc-patches; +Cc: amodra

We currently test flag_merge_constants when deciding whether to merge
DWARF debugging strings.  This is to avoid slowing down the linker.
It was proposed here:
    http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00364.html
raised again here:
    http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02293.html
and approved here:
    http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00233.html

I personally disagree with the analysis that this problem should be
solved in the compiler.  The linker is not required to support merging
constants in SHF_MERGE sections, and it is not required to handle
SHF_MERGE the same regardless of whether SHF_ALLOC is set or not.  I
think it would be perfectly reasonable for the linker to have an
option controlling whether it should merge string constants.

Also the linker should automatically grow the hash table to speed it
up.  It does this now by default.

Even if we decide that the compiler should control this, it makes no
sense to base it on flag_merge_constants.  That is an optimization
option, turned on by default with -O.  An optimization option should
not affect the debugging information.

This is the simple patch to preserve the functionality in the
compiler, by adding a new -fmerge-debug-strings option.  I made the
option default to on, as I believe the current linker will not have
the same problems.

Does anybody have any comments or objections to this approach?

Ian


2007-11-16  Ian Lance Taylor  <iant@google.com>

	* common.opt (fmerge-debug-strings): New option.
	* dwarf2out.c (DEBUG_STR_SECTION_FLAGS): Test
	flag_merge_debug_strings rather than flag_merge_constants.
	* doc/invoke.texi (Option Summary): Mention
	-fmerge-debug-strings.
	(Debugging Options): Document -fmerge-debug-strings.


Index: doc/invoke.texi
===================================================================
--- doc/invoke.texi	(revision 130217)
+++ doc/invoke.texi	(working copy)
@@ -304,7 +304,7 @@ Objective-C and Objective-C++ Dialects}.
 -ftest-coverage  -ftime-report -fvar-tracking @gol
 -g  -g@var{level}  -gcoff -gdwarf-2 @gol
 -ggdb  -gstabs  -gstabs+  -gvms  -gxcoff  -gxcoff+ @gol
--fdebug-prefix-map=@var{old}=@var{new} @gol
+-fmerge-debug-strings -fdebug-prefix-map=@var{old}=@var{new} @gol
 -femit-struct-debug-baseonly -femit-struct-debug-reduced @gol
 -femit-struct-debug-detailed@r{[}=@var{spec-list}@r{]} @gol
 -p  -pg  -print-file-name=@var{library}  -print-libgcc-file-name @gol
@@ -4153,6 +4153,14 @@ The default is @samp{-femit-struct-debug
 
 This option works only with DWARF 2.
 
+@item -fmerge-debug-strings
+@opindex fmerge-debug-strings
+Direct the linker to merge together strings which are identical in
+different object files.  This is not supported by all assemblers or
+linker.  This decreases the size of the debug information in the
+output file at the cost of increasing link processing time.  This is
+on by default.
+
 @item -fdebug-prefix-map=@var{old}=@var{new}
 @opindex fdebug-prefix-map
 When compiling files in directory @file{@var{old}}, record debugging
Index: dwarf2out.c
===================================================================
--- dwarf2out.c	(revision 130217)
+++ dwarf2out.c	(working copy)
@@ -4355,7 +4355,7 @@ static int maybe_emit_file (struct dwarf
 
 /* Section flags for .debug_str section.  */
 #define DEBUG_STR_SECTION_FLAGS \
-  (HAVE_GAS_SHF_MERGE && flag_merge_constants			\
+  (HAVE_GAS_SHF_MERGE && flag_merge_debug_strings		\
    ? SECTION_DEBUG | SECTION_MERGE | SECTION_STRINGS | 1	\
    : SECTION_DEBUG)
 
Index: common.opt
===================================================================
--- common.opt	(revision 130217)
+++ common.opt	(working copy)
@@ -666,6 +666,10 @@ fmerge-constants
 Common Report Var(flag_merge_constants,1) VarExists Optimization
 Attempt to merge identical constants across compilation units
 
+fmerge-debug-strings
+Common Report Var(flag_merge_debug_strings) Init(1)
+Attempt to merge identical debug strings across compilation units
+
 fmessage-length=
 Common RejectNegative Joined UInteger
 -fmessage-length=<number>	Limit diagnostics to <number> characters per line.  0 suppresses line-wrapping

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: PATCH RFC: Add -fmerge-debug-strings option
  2007-11-17  5:42 PATCH RFC: Add -fmerge-debug-strings option Ian Lance Taylor
@ 2007-11-24 10:42 ` Mark Mitchell
  2007-11-24 11:09   ` Manuel López-Ibáñez
  0 siblings, 1 reply; 3+ messages in thread
From: Mark Mitchell @ 2007-11-24 10:42 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: gcc-patches, amodra

Ian Lance Taylor wrote:

> 2007-11-16  Ian Lance Taylor  <iant@google.com>
> 
> 	* common.opt (fmerge-debug-strings): New option.
> 	* dwarf2out.c (DEBUG_STR_SECTION_FLAGS): Test
> 	flag_merge_debug_strings rather than flag_merge_constants.
> 	* doc/invoke.texi (Option Summary): Mention
> 	-fmerge-debug-strings.
> 	(Debugging Options): Document -fmerge-debug-strings.

I agree with you and I think this patch should be checked in.

> +@item -fmerge-debug-strings
> +@opindex fmerge-debug-strings
> +Direct the linker to merge together strings which are identical in
> +different object files.  This is not supported by all assemblers or
> +linker.  This decreases the size of the debug information in the

"linkers"

> +output file at the cost of increasing link processing time.  This is
> +on by default.

Do we have a convention about whether we document -ffoo or -fno-foo in
the manual?  (I could imagine documenting -fno-foo for options on by
default, since -fno-foo is probably what users would want to know how to
use.)

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: PATCH RFC: Add -fmerge-debug-strings option
  2007-11-24 10:42 ` Mark Mitchell
@ 2007-11-24 11:09   ` Manuel López-Ibáñez
  0 siblings, 0 replies; 3+ messages in thread
From: Manuel López-Ibáñez @ 2007-11-24 11:09 UTC (permalink / raw)
  To: Mark Mitchell; +Cc: Ian Lance Taylor, gcc-patches, amodra

On 24/11/2007, Mark Mitchell <mark@codesourcery.com> wrote:

> Do we have a convention about whether we document -ffoo or -fno-foo in
> the manual?  (I could imagine documenting -fno-foo for options on by
> default, since -fno-foo is probably what users would want to know how to
> use.)
>

Yes, we document whatever is not on by default. But, it would be
better to include both forms in the index by using
@opindex -ffoo
@opindex -fno-foo

Cheers,

Manuel.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2007-11-24  2:12 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-11-17  5:42 PATCH RFC: Add -fmerge-debug-strings option Ian Lance Taylor
2007-11-24 10:42 ` Mark Mitchell
2007-11-24 11:09   ` Manuel López-Ibáñez

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).