| Message ID | yddtx8if35c.fsf@lokon.CeBiTec.Uni-Bielefeld.DE |
|---|---|
| State | New |
| Headers | show |
On Thu, 22 May 2014, Rainer Orth wrote: > * common.opt (compressed_debug_sections): New enum. > (gz, gz=): New options. > * opts.c (common_handle_option): Handle OPT_gz, OPT_gz_. Given that the options are completely handled via specs, why can't they just be Driver options (without Common) and so not mentioned in common_handle_option?
"Joseph S. Myers" <joseph@codesourcery.com> writes: > On Thu, 22 May 2014, Rainer Orth wrote: > >> * common.opt (compressed_debug_sections): New enum. >> (gz, gz=): New options. > >> * opts.c (common_handle_option): Handle OPT_gz, OPT_gz_. > > Given that the options are completely handled via specs, why can't they > just be Driver options (without Common) and so not mentioned in > common_handle_option? If I do this, -gz still gets passed to e.g. cc1, which errors out like this: cc1: error: unrecognised debug output level "z" It seems my way of handling this is clearer than doing this in opts.c (set_debug_level). Rainer
On Thu, 22 May 2014, Rainer Orth wrote: > "Joseph S. Myers" <joseph@codesourcery.com> writes: > > > On Thu, 22 May 2014, Rainer Orth wrote: > > > >> * common.opt (compressed_debug_sections): New enum. > >> (gz, gz=): New options. > > > >> * opts.c (common_handle_option): Handle OPT_gz, OPT_gz_. > > > > Given that the options are completely handled via specs, why can't they > > just be Driver options (without Common) and so not mentioned in > > common_handle_option? > > If I do this, -gz still gets passed to e.g. cc1, which errors out like > this: > > cc1: error: unrecognised debug output level "z" > > It seems my way of handling this is clearer than doing this in opts.c > (set_debug_level). Thanks for the explanation. The driver changes are OK.
"Joseph S. Myers" <joseph@codesourcery.com> writes: > On Thu, 22 May 2014, Rainer Orth wrote: > >> "Joseph S. Myers" <joseph@codesourcery.com> writes: >> >> > On Thu, 22 May 2014, Rainer Orth wrote: >> > >> >> * common.opt (compressed_debug_sections): New enum. >> >> (gz, gz=): New options. >> > >> >> * opts.c (common_handle_option): Handle OPT_gz, OPT_gz_. >> > >> > Given that the options are completely handled via specs, why can't they >> > just be Driver options (without Common) and so not mentioned in >> > common_handle_option? >> >> If I do this, -gz still gets passed to e.g. cc1, which errors out like >> this: >> >> cc1: error: unrecognised debug output level "z" >> >> It seems my way of handling this is clearer than doing this in opts.c >> (set_debug_level). > > Thanks for the explanation. The driver changes are OK. Thanks. I still need approval for the doc and build parts, as well as the Darwin and DJGPP changes. For the latter two, I've included the patch in a x86_64-apple-darwin11.4.2 build, verifying that -gz is rejected as expected (no idea if the are any working gas and gold ports that would support the option). For DJGPP, I've tried a i386-pc-solaris2.11 x i586-pc-msdosdjgpp cross. While the specs additions look correct, trying to compile even the most trivial program SEGVs: ro@snoopy 319 > ./xgcc -B./ -o hello hello.c <built-in>: internal compiler error: Segmentation Fault 0x87549df crash_signal /vol/gcc/src/hg/trunk/local/gcc/toplev.c:337 0x82b8270 contains_struct_check /vol/gcc/src/hg/trunk/local/gcc/tree.h:2841 0x82b8270 c_common_nodes_and_builtins() /vol/gcc/src/hg/trunk/local/gcc/c-family/c-common.c:5619 0x82437be c_init_decl_processing() /vol/gcc/src/hg/trunk/local/gcc/c/c-decl.c:3567 0x827fe1a c_objc_common_init() /vol/gcc/src/hg/trunk/local/gcc/c/c-objc-common.c:63 0x8756333 lang_dependent_init /vol/gcc/src/hg/trunk/local/gcc/toplev.c:1712 0x8756333 do_compile /vol/gcc/src/hg/trunk/local/gcc/toplev.c:1901 Rainer
> Thanks. I still need approval for the doc and build parts, as well > as the Darwin and DJGPP changes. For the latter two, I've included > the I'll approve the DJGPP change, despite the segv. I suspect it's unrelated.
Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes: > "Joseph S. Myers" <joseph@codesourcery.com> writes: [...] >> Thanks for the explanation. The driver changes are OK. > > Thanks. I still need approval for the doc and build parts, as well as > the Darwin and DJGPP changes. For the latter two, I've included the > patch in a x86_64-apple-darwin11.4.2 build, verifying that -gz is > rejected as expected (no idea if the are any working gas and gold ports > that would support the option). For DJGPP, I've tried a > i386-pc-solaris2.11 x i586-pc-msdosdjgpp cross. While the specs > additions look correct, trying to compile even the most trivial program > SEGVs: [...] It's been another week, and I still need approval for the build, doc, and Darwin changes: https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01860.html Thanks. Rainer
On Jun 3, 2014, at 3:40 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote: > It's been another week, and I still need approval for the build, doc, > and Darwin changes: So, the darwin bits look trivial enough, if the entire scheme is what people want to do. My question would be, why do we want an option for this? If the scheme works, why not just turn it on unconditionally? If it doesn’t work, why add it? If it isn’t good, why add it? If it is good, why not do it? If it is just to reach compatibility with the debugger, then I’d rather either just mandate a certain debugger or autoconf for what the current debugger supports. As of late people seem to just break the debugging experience with non-updated gdbs and assume that a newer gdb is used.
On Tue, 3 Jun 2014, Rainer Orth wrote: > It's been another week, and I still need approval for the build, doc, > and Darwin changes: > > https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01860.html On the doc side, things are fine. Just a suggestion or two: +Produce compressed debug sections in DWARF format, if that is supported. Supported by what? "doesn't" -> "does not", especially given the emphasis we want to make here. And could the "If the linker doesn't support writing compressed debug sections, the option is rejected. Otherwise, if the assembler doesn't support them, @option{-gz} is silently ignored when producing object files." be moved to the very end, or is this only applicable to the case where no type has been specified? Gerald
Mike Stump <mikestump@comcast.net> writes: > On Jun 3, 2014, at 3:40 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote: >> It's been another week, and I still need approval for the build, doc, >> and Darwin changes: > > So, the darwin bits look trivial enough, if the entire scheme is what > people want to do. My question would be, why do we want an option for > this? If the scheme works, why not just turn it on unconditionally? If it > doesn’t work, why add it? If it isn’t good, why add it? If it is good, > why not do it? It works in very specific circumstances, like assembler and linker versions. > If it is just to reach compatibility with the debugger, then I’d rather > either just mandate a certain debugger or autoconf for what the current > debugger supports. As of late people seem to just break the debugging > experience with non-updated gdbs and assume that a newer gdb is used. You cannot do that: unlike the assembler and linker used, which are often hardcoded into gcc, the debugger can easily be changed below the compiler's feet, so to speak. Besides, on several platforms, you have more than one debugger available (like gdb and dbx, or others), so this isn't an option. Apart from that, the debugging experience when e.g. emitting very recent DWARF extensions and trying to use them with a gdb that doesn't understand them usually leads to some debug info missing. In this case, emitting compressed debug with a debugger that cannot read it leads to the debugger claiming (correctly, from its point of view) that there's no debugging info present. I don't want to tell users who come complaining `I compiled with -g, but my debugger tells me there's no debug info present': `look, your debugger lies, it is present, but it cannot read it'. That's a lot worse than the DWARF extensions scenario above. On top of all that, compressed debug is a tradeoff: in some cases it may be worth it to save space on debug info if disk space is at a premium for some reason (e.g. for release builds), but in others you want to compile as fast as possible, but assembling and linking compressed debug takes more CPU time. Otherwise we could just as well default to -Os, telling our users it's better for them since it generates faster and smaller code, not minding the compile time cost and worse debugging experience. I at least don't wont to patronize our users like this. Rainer
On Jun 4, 2014, at 1:54 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote: > Mike Stump <mikestump@comcast.net> writes: >> On Jun 3, 2014, at 3:40 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote: >>> It's been another week, and I still need approval for the build, doc, >>> and Darwin changes: >> >> So, the darwin bits look trivial enough, if the entire scheme is what >> people want to do. The darwin bits are Ok.
>> If it is just to reach compatibility with the debugger, then I’d rather >> either just mandate a certain debugger or autoconf for what the current >> debugger supports. As of late people seem to just break the debugging >> experience with non-updated gdbs and assume that a newer gdb is used. > > You cannot do that: unlike the assembler and linker used, which are > often hardcoded into gcc, the debugger can easily be changed below the > compiler's feet, so to speak. Besides, on several platforms, you have > more than one debugger available (like gdb and dbx, or others), so this > isn't an option. Apart from that, the debugging experience when > e.g. emitting very recent DWARF extensions and trying to use them with a > gdb that doesn't understand them usually leads to some debug info > missing. In this case, emitting compressed debug with a debugger that > cannot read it leads to the debugger claiming (correctly, from its > point of view) that there's no debugging info present. I don't want to > tell users who come complaining `I compiled with -g, but my debugger > tells me there's no debug info present': `look, your debugger lies, it > is present, but it cannot read it'. That's a lot worse than the > DWARF extensions scenario above. > Agreed :) FWIW it's already a gas/assembler option, I'm curious about wanting to expose it via the compiler? > On top of all that, compressed debug is a tradeoff: in some cases it may > be worth it to save space on debug info if disk space is at a premium > for some reason (e.g. for release builds), but in others you want to > compile as fast as possible, but assembling and linking compressed debug > takes more CPU time. Otherwise we could just as well default to -Os, > telling our users it's better for them since it generates faster and > smaller code, not minding the compile time cost and worse debugging > experience. > FWIW I've found in some limited timing that compression is nearly always worth it here at Google - even for compile time given the cost of writing files versus cpu time. Might be worth making it a default at some point in the future and making sure the option is invertible. -eric
Hi Gerald, sorry for the delay, I've been away for a couple of days. > On Tue, 3 Jun 2014, Rainer Orth wrote: >> It's been another week, and I still need approval for the build, doc, >> and Darwin changes: >> >> https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01860.html > > On the doc side, things are fine. > > Just a suggestion or two: > > +Produce compressed debug sections in DWARF format, if that is supported. > > Supported by what? By the toolchain used. TBH, I just copied that fragment from various other debug options (-gstabs, -gcoff, -gdwarf-N). Given the precedent and the verbosity of a more detailed explanation, I'd leave this as is. > "doesn't" -> "does not", especially given the emphasis we want to make > here. Good point, fixed. > And could the "If the linker doesn't support writing compressed debug > sections, the option is rejected. Otherwise, if the assembler doesn't > support them, @option{-gz} is silently ignored when producing object > files." be moved to the very end, or is this only applicable to the > case where no type has been specified? No, you're right: it's better to first explain the values for type in the working case, then explain potential error scenarios. The section now reads @item -gz@r{[}=@var{type}@r{]} @opindex gz Produce compressed debug sections in DWARF format, if that is supported. If @var{type} is not given, the default type depends on the capabilities of the assembler and linker used. @var{type} may be one of @option{none} (don't compress debug sections), @option{zlib} (use zlib compression in ELF gABI format), or @option{zlib-gnu} (use zlib compression in traditional GNU format). If the linker doesn't support writing compressed debug sections, the option is rejected. Otherwise, if the assembler does not support them, @option{-gz} is silently ignored when producing object files. Thanks for your comments. I'm still missing review of the build parts after three weeks and several reminders, though. Paolo, Nathanael, Alexandre, could one of you please have a look? Thanks. Rainer
Eric Christopher <echristo@gmail.com> writes: >>> If it is just to reach compatibility with the debugger, then I’d rather >>> either just mandate a certain debugger or autoconf for what the current >>> debugger supports. As of late people seem to just break the debugging >>> experience with non-updated gdbs and assume that a newer gdb is used. >> >> You cannot do that: unlike the assembler and linker used, which are >> often hardcoded into gcc, the debugger can easily be changed below the >> compiler's feet, so to speak. Besides, on several platforms, you have >> more than one debugger available (like gdb and dbx, or others), so this >> isn't an option. Apart from that, the debugging experience when >> e.g. emitting very recent DWARF extensions and trying to use them with a >> gdb that doesn't understand them usually leads to some debug info >> missing. In this case, emitting compressed debug with a debugger that >> cannot read it leads to the debugger claiming (correctly, from its >> point of view) that there's no debugging info present. I don't want to >> tell users who come complaining `I compiled with -g, but my debugger >> tells me there's no debug info present': `look, your debugger lies, it >> is present, but it cannot read it'. That's a lot worse than the >> DWARF extensions scenario above. > > Agreed :) > > FWIW it's already a gas/assembler option, I'm curious about wanting to > expose it via the compiler? One reason: ease of use: * -gz is far easier to use/type than -Wa,--compress-debug-sections + -Wl,--compress-debug-sections, and * one common option irrespective of assemblers (the Solaris assembler will gain eventually gain compressed debug support, too) and linkers used (Solaris ld requires -z compress-sections=<type>), and even the Apple assembler might at some point ;-) >> On top of all that, compressed debug is a tradeoff: in some cases it may >> be worth it to save space on debug info if disk space is at a premium >> for some reason (e.g. for release builds), but in others you want to >> compile as fast as possible, but assembling and linking compressed debug >> takes more CPU time. Otherwise we could just as well default to -Os, >> telling our users it's better for them since it generates faster and >> smaller code, not minding the compile time cost and worse debugging >> experience. > > FWIW I've found in some limited timing that compression is nearly > always worth it here at Google - even for compile time given the cost > of writing files versus cpu time. Might be worth making it a default > at some point in the future and making sure the option is invertible. One might be not so lucky with different/slower CPUs, though. I wonder how this would affect bootstrap times on my current SPARC systems ;-( But yes, a configure option to default -gz to on would certainly be helpful at some point. Rainer
Il 26/06/2014 15:16, Rainer Orth ha scritto: > Hi Gerald, > > sorry for the delay, I've been away for a couple of days. > >> On Tue, 3 Jun 2014, Rainer Orth wrote: >>> It's been another week, and I still need approval for the build, doc, >>> and Darwin changes: >>> >>> https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01860.html >> >> On the doc side, things are fine. >> >> Just a suggestion or two: >> >> +Produce compressed debug sections in DWARF format, if that is supported. >> >> Supported by what? > > By the toolchain used. TBH, I just copied that fragment from various > other debug options (-gstabs, -gcoff, -gdwarf-N). Given the precedent > and the verbosity of a more detailed explanation, I'd leave this as is. > >> "doesn't" -> "does not", especially given the emphasis we want to make >> here. > > Good point, fixed. > >> And could the "If the linker doesn't support writing compressed debug >> sections, the option is rejected. Otherwise, if the assembler doesn't >> support them, @option{-gz} is silently ignored when producing object >> files." be moved to the very end, or is this only applicable to the >> case where no type has been specified? > > No, you're right: it's better to first explain the values for type in > the working case, then explain potential error scenarios. > > The section now reads > > @item -gz@r{[}=@var{type}@r{]} > @opindex gz > Produce compressed debug sections in DWARF format, if that is supported. > If @var{type} is not given, the default type depends on the capabilities > of the assembler and linker used. @var{type} may be one of > @option{none} (don't compress debug sections), @option{zlib} (use zlib > compression in ELF gABI format), or @option{zlib-gnu} (use zlib > compression in traditional GNU format). If the linker doesn't support > writing compressed debug sections, the option is rejected. Otherwise, > if the assembler does not support them, @option{-gz} is silently ignored > when producing object files. > > Thanks for your comments. > > I'm still missing review of the build parts after three weeks and > several reminders, though. Paolo, Nathanael, Alexandre, could one of > you please have a look? Build changes are good, thanks. Paolo
On Thu, Jun 26, 2014 at 6:32 AM, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote: > Eric Christopher <echristo@gmail.com> writes: > >>>> If it is just to reach compatibility with the debugger, then I’d rather >>>> either just mandate a certain debugger or autoconf for what the current >>>> debugger supports. As of late people seem to just break the debugging >>>> experience with non-updated gdbs and assume that a newer gdb is used. >>> >>> You cannot do that: unlike the assembler and linker used, which are >>> often hardcoded into gcc, the debugger can easily be changed below the >>> compiler's feet, so to speak. Besides, on several platforms, you have >>> more than one debugger available (like gdb and dbx, or others), so this >>> isn't an option. Apart from that, the debugging experience when >>> e.g. emitting very recent DWARF extensions and trying to use them with a >>> gdb that doesn't understand them usually leads to some debug info >>> missing. In this case, emitting compressed debug with a debugger that >>> cannot read it leads to the debugger claiming (correctly, from its >>> point of view) that there's no debugging info present. I don't want to >>> tell users who come complaining `I compiled with -g, but my debugger >>> tells me there's no debug info present': `look, your debugger lies, it >>> is present, but it cannot read it'. That's a lot worse than the >>> DWARF extensions scenario above. >> >> Agreed :) >> >> FWIW it's already a gas/assembler option, I'm curious about wanting to >> expose it via the compiler? > > One reason: ease of use: > > * -gz is far easier to use/type than -Wa,--compress-debug-sections + > -Wl,--compress-debug-sections, and > Very true. Maybe make it a -gcompress-dwarf-sections? > * one common option irrespective of assemblers (the Solaris assembler > will gain eventually gain compressed debug support, too) and linkers > used (Solaris ld requires -z compress-sections=<type>), and even the > Apple assembler might at some point ;-) > The assembler itself does, but as far as I know none of the consumers can deal with it. Right now it supports the same options as gas. >>> On top of all that, compressed debug is a tradeoff: in some cases it may >>> be worth it to save space on debug info if disk space is at a premium >>> for some reason (e.g. for release builds), but in others you want to >>> compile as fast as possible, but assembling and linking compressed debug >>> takes more CPU time. Otherwise we could just as well default to -Os, >>> telling our users it's better for them since it generates faster and >>> smaller code, not minding the compile time cost and worse debugging >>> experience. >> >> FWIW I've found in some limited timing that compression is nearly >> always worth it here at Google - even for compile time given the cost >> of writing files versus cpu time. Might be worth making it a default >> at some point in the future and making sure the option is invertible. > > One might be not so lucky with different/slower CPUs, though. I wonder > how this would affect bootstrap times on my current SPARC systems ;-( > I'd have thought you'd still largely be write bound for compilation. *shrug* > But yes, a configure option to default -gz to on would certainly be > helpful at some point. *nod* -eric
# HG changeset patch # Parent 461334df01269c96bf9f041380cfc901c395307d Enable --compress-debug-sections diff --git a/gcc/common.opt b/gcc/common.opt --- a/gcc/common.opt +++ b/gcc/common.opt @@ -2518,6 +2518,28 @@ gxcoff+ Common JoinedOrMissing Negative(gcoff) Generate debug information in extended XCOFF format +Enum +Name(compressed_debug_sections) Type(int) + +; Since -gz= is completely handled in specs, the values aren't used and we +; assign arbitrary constants. +EnumValue +Enum(compressed_debug_sections) String(none) Value(0) + +EnumValue +Enum(compressed_debug_sections) String(zlib) Value(1) + +EnumValue +Enum(compressed_debug_sections) String(zlib-gnu) Value(2) + +gz +Common Driver +Generate compressed debug sections + +gz= +Common Driver Joined Enum(compressed_debug_sections) +-gz=<format> Generate compressed debug sections in format <format> + h Driver Joined Separate diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h --- a/gcc/config/darwin.h +++ b/gcc/config/darwin.h @@ -171,7 +171,8 @@ extern GTY(()) int darwin_ms_struct; LINK_PLUGIN_SPEC \ "%{flto*:%<fcompare-debug*} \ %{flto*} \ - %l %X %{s} %{t} %{Z} %{u*} \ + %l " LINK_COMPRESS_DEBUG_SPEC \ + "%X %{s} %{t} %{Z} %{u*} \ %{e*} %{r} \ %{o*}%{!o:-o a.out} \ %{!nostdlib:%{!nostartfiles:%S}} \ diff --git a/gcc/config/i386/djgpp.h b/gcc/config/i386/djgpp.h --- a/gcc/config/i386/djgpp.h +++ b/gcc/config/i386/djgpp.h @@ -80,7 +80,8 @@ along with GCC; see the file COPYING3. #undef LINK_COMMAND_SPEC #define LINK_COMMAND_SPEC \ "%{!fsyntax-only: \ -%{!c:%{!M:%{!MM:%{!E:%{!S:%(linker) %l %X %{o*} %{e*} %{N} %{n} \ +%{!c:%{!M:%{!MM:%{!E:%{!S:%(linker) %l " LINK_COMPRESS_DEBUG_SPEC \ +"%X %{o*} %{e*} %{N} %{n} \ \t%{r} %{s} %{t} %{u*} %{z} %{Z}\ \t%{!nostdlib:%{!nostartfiles:%S}}\ \t%{static:} %{L*} %D %o\ diff --git a/gcc/configure.ac b/gcc/configure.ac --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -4370,6 +4370,30 @@ if test x"$insn" != x; then [Define if your assembler supports the --debug-prefix-map option.])]) fi +gcc_GAS_CHECK_FEATURE([compressed debug sections], + gcc_cv_as_compress_debug,,[--compress-debug-sections],, + [# gas compiled without zlib cannot compress debug sections and warns + # about it, but still exits successfully. So check for this, too. + if $gcc_cv_as --compress-debug-sections -o conftest.o conftest.s 2>&1 | grep -i warning > /dev/null + then + gcc_cv_as_compress_debug=0 + elif $gcc_cv_as --compress-debug-sections -o conftest.o conftest.s > /dev/null 2>&1 + then + gcc_cv_as_compress_debug=1 + gcc_cv_as_compress_debug_option="--compress-debug-sections" + gcc_cv_as_no_compress_debug_option="--nocompress-debug-sections" + else + gcc_cv_as_compress_debug=0 + # FIXME: Future gas versions will support ELF gABI style via + # --compress-debug-sections[=type]. + fi]) +AC_DEFINE_UNQUOTED(HAVE_AS_COMPRESS_DEBUG, $gcc_cv_as_compress_debug, +[Define to the level of your assembler's compressed debug section support.]) +AC_DEFINE_UNQUOTED(AS_COMPRESS_DEBUG_OPTION, "$gcc_cv_as_compress_debug_option", +[Define to the assembler option to enable compressed debug sections.]) +AC_DEFINE_UNQUOTED(AS_NO_COMPRESS_DEBUG_OPTION, "$gcc_cv_as_no_compress_debug_option", +[Define to the assembler option to disable compressed debug sections.]) + gcc_GAS_CHECK_FEATURE([.lcomm with alignment], gcc_cv_as_lcomm_with_alignment, ,, [.lcomm bar,4,16],, @@ -4676,6 +4700,60 @@ if test x$gcc_cv_ld_eh_gc_sections_bug = fi AC_MSG_RESULT($gcc_cv_ld_eh_gc_sections_bug) +AC_MSG_CHECKING(linker for compressed debug sections) +# gold/gld support compressed debug sections since binutils 2.19/2.21 +if test $in_tree_ld = yes ; then + gcc_cv_ld_compress_debug=0 + if test "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" -ge 19 -o "$gcc_cv_gld_major_version" -gt 2 \ + && test $in_tree_ld_is_elf = yes && test $ld_is_gold = yes; then + gcc_cv_ld_compress_debug=2 + gcc_cv_ld_compress_debug_option="--compress-debug-sections" + elif test "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" -ge 21 -o "$gcc_cv_gld_major_version" -gt 2 \ + && test $in_tree_ld_is_elf = yes; then + gcc_cv_ld_compress_debug=1 + fi +elif echo "$ld_ver" | grep GNU > /dev/null; then + gcc_cv_ld_compress_debug=1 + if test 0"$ld_date" -lt 20050308; then + if test -n "$ld_date"; then + # If there was date string, but was earlier than 2005-03-08, fail + gcc_cv_ld_compress_debug=0 + elif test "$ld_vers_major" -lt 2; then + gcc_cv_ld_compress_debug=0 + elif test "$ld_vers_major" -eq 2 -a "$ld_vers_minor" -lt 21; then + gcc_cv_ld_compress_debug=0 + fi + fi + if test $ld_is_gold = yes; then + gcc_cv_ld_compress_debug=2 + gcc_cv_ld_compress_debug_option="--compress-debug-sections" + fi +else +changequote(,)dnl + case "${target}" in + *-*-solaris2*) + # Introduced in Solaris 11.2. + if $gcc_cv_ld --help 2>&1 | grep -- '-z compress-sections' > /dev/null; then + gcc_cv_ld_compress_debug=3 + gcc_cv_ld_compress_debug_option="-z compress-sections" + else + gcc_cv_ld_compress_debug=0 + fi + ;; + *) + # Assume linkers other than GNU ld don't support compessed debug + # sections. + gcc_cv_ld_compress_debug=0 + ;; + esac +changequote([,])dnl +fi +AC_DEFINE_UNQUOTED(HAVE_LD_COMPRESS_DEBUG, $gcc_cv_ld_compress_debug, +[Define to the level of your linker's compressed debug section support.]) +AC_DEFINE_UNQUOTED(LD_COMPRESS_DEBUG_OPTION, "$gcc_cv_ld_compress_debug_option", +[Define to the linker option to enable compressed debug sections.]) +AC_MSG_RESULT($gcc_cv_ld_compress_debug) + # -------- # UNSORTED # -------- diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -344,7 +344,7 @@ Objective-C and Objective-C++ Dialects}. -g -g@var{level} -gtoggle -gcoff -gdwarf-@var{version} @gol -ggdb -grecord-gcc-switches -gno-record-gcc-switches @gol -gstabs -gstabs+ -gstrict-dwarf -gno-strict-dwarf @gol --gvms -gxcoff -gxcoff+ @gol +-gvms -gxcoff -gxcoff+ -gz@r{[}=@var{type}@r{]} @gol -fno-merge-debug-strings -fno-dwarf2-cfi-asm @gol -fdebug-prefix-map=@var{old}=@var{new} @gol -femit-struct-debug-baseonly -femit-struct-debug-reduced @gol @@ -5274,6 +5274,18 @@ DWARF extensions from later standard ver Allow using extensions of later DWARF standard version than selected with @option{-gdwarf-@var{version}}. +@item -gz@r{[}=@var{type}@r{]} +@opindex gz +Produce compressed debug sections in DWARF format, if that is supported. +If @var{type} is not given, the default type depends on the capabilities +of the assembler and linker used. If the linker doesn't support writing +compressed debug sections, the option is rejected. Otherwise, if the +assembler doesn't support them, @option{-gz} is silently ignored when +producing object files. @var{type} may be one of @option{none} (don't +compress debug sections), @option{zlib} (use zlib compression in ELF +gABI format), or @option{zlib-gnu} (use zlib compression in traditional +GNU format). + @item -gvms @opindex gvms Produce debugging information in Alpha/VMS debug format (if that is diff --git a/gcc/gcc.c b/gcc/gcc.c --- a/gcc/gcc.c +++ b/gcc/gcc.c @@ -597,6 +597,31 @@ proper position among the other output f #endif #endif +/* Linker options for compressed debug sections. */ +#if HAVE_LD_COMPRESS_DEBUG == 0 +/* No linker support. */ +#define LINK_COMPRESS_DEBUG_SPEC \ + " %{gz*:%e-gz is not supported in this configuration} " +#elif HAVE_LD_COMPRESS_DEBUG == 1 +/* GNU style on input, GNU ld options. Reject, not useful. */ +#define LINK_COMPRESS_DEBUG_SPEC \ + " %{gz*:%e-gz is not supported in this configuration} " +#elif HAVE_LD_COMPRESS_DEBUG == 2 +/* GNU style, GNU gold options. */ +#define LINK_COMPRESS_DEBUG_SPEC \ + " %{gz|gz=zlib-gnu:" LD_COMPRESS_DEBUG_OPTION "=zlib}" \ + " %{gz=none:" LD_COMPRESS_DEBUG_OPTION "=none}" \ + " %{gz=zlib:%e-gz=zlib is not supported in this configuration} " +#elif HAVE_LD_COMPRESS_DEBUG == 3 +/* ELF gABI style. */ +#define LINK_COMPRESS_DEBUG_SPEC \ + " %{gz|gz=zlib:" LD_COMPRESS_DEBUG_OPTION "=zlib}" \ + " %{gz=none:" LD_COMPRESS_DEBUG_OPTION "=none}" \ + " %{gz=zlib-gnu:" LD_COMPRESS_DEBUG_OPTION "=zlib-gnu} " +#else +#error Unknown value for HAVE_LD_COMPRESS_DEBUG. +#endif + /* config.h can define LIBGCC_SPEC to override how and when libgcc.a is included. */ #ifndef LIBGCC_SPEC @@ -631,6 +656,33 @@ proper position among the other output f #define ASM_MAP "" #endif +/* Assembler options for compressed debug sections. */ +#if HAVE_LD_COMPRESS_DEBUG < 2 +/* Reject if the linker cannot write compressed debug sections. */ +#define ASM_COMPRESS_DEBUG_SPEC \ + " %{gz*:%e-gz is not supported in this configuration} " +#else /* HAVE_LD_COMPRESS_DEBUG >= 2 */ +#if HAVE_AS_COMPRESS_DEBUG == 0 +/* No assembler support. Ignore silently. */ +#define ASM_COMPRESS_DEBUG_SPEC \ + " %{gz*:} " +#elif HAVE_AS_COMPRESS_DEBUG == 1 +/* GNU style, GNU as options. */ +#define ASM_COMPRESS_DEBUG_SPEC \ + " %{gz|gz=zlib-gnu:" AS_COMPRESS_DEBUG_OPTION "}" \ + " %{gz=none:" AS_NO_COMPRESS_DEBUG_OPTION "}" \ + " %{gz=zlib:%e-gz=zlib is not supported in this configuration} " +#elif HAVE_AS_COMPRESS_DEBUG == 2 +/* ELF gABI style. */ +#define ASM_COMPRESS_DEBUG_SPEC \ + " %{gz|gz=zlib:" AS_COMPRESS_DEBUG_OPTION "=zlib}" \ + " %{gz=none:" AS_COMPRESS_DEBUG_OPTION "=none}" \ + " %{gz=zlib-gnu:" AS_COMPRESS_DEBUG_OPTION "=zlib-gnu} " +#else +#error Unknown value for HAVE_AS_COMPRESS_DEBUG. +#endif +#endif /* HAVE_LD_COMPRESS_DEBUG >= 2 */ + /* Define ASM_DEBUG_SPEC to be a spec suitable for translating '-g' to the assembler. */ #ifndef ASM_DEBUG_SPEC @@ -761,8 +813,8 @@ proper position among the other output f LINK_PLUGIN_SPEC \ "%{flto|flto=*:%<fcompare-debug*} \ %{flto} %{flto=*} %l " LINK_PIE_SPEC \ - "%{fuse-ld=*:-fuse-ld=%*}\ - %X %{o*} %{e*} %{N} %{n} %{r}\ + "%{fuse-ld=*:-fuse-ld=%*} " LINK_COMPRESS_DEBUG_SPEC \ + "%X %{o*} %{e*} %{N} %{n} %{r}\ %{s} %{t} %{u*} %{z} %{Z} %{!nostdlib:%{!nostartfiles:%S}} " VTABLE_VERIFICATION_SPEC " \ %{static:} %{L*} %(mfwrap) %(link_libgcc) " SANITIZER_EARLY_SPEC " %o\ %{fopenmp|ftree-parallelize-loops=*:%:include(libgomp.spec)%(link_gomp)}\ @@ -885,6 +937,7 @@ static const char *asm_options = to the assembler equivalents. */ "%{v} %{w:-W} %{I*} " #endif +ASM_COMPRESS_DEBUG_SPEC "%a %Y %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}"; static const char *invoke_as = diff --git a/gcc/opts.c b/gcc/opts.c --- a/gcc/opts.c +++ b/gcc/opts.c @@ -1867,6 +1867,11 @@ common_handle_option (struct gcc_options loc); break; + case OPT_gz: + case OPT_gz_: + /* Handled completely via specs. */ + break; + case OPT_pedantic_errors: dc->pedantic_errors = 1; control_warning_option (OPT_Wpedantic, DK_ERROR, value,