| Message ID | 20130213155423.GW4385@tucnak.redhat.com |
|---|---|
| State | New |
| Headers | show |
On 02/13/13 08:54, Jakub Jelinek wrote: > Hi! > > As agreed on in the PR, here is the revertion of 3 commits, so that > PCH works again for -gstabs and other debug info formats for 4.8 > release. For 4.9 we should either remove support for anything non-DWARF, or > hope somebody steps up and fixes dbxout.c etc. not to emit debug info right > away, but queue it till end of compilation. > > Bootstrapped/regtested on x86_64-linux and i686-linux, additionally tested > with > make check RUNTESTFLAGS='--target_board=unix\{-m32,-m32/-gstabs,-m64,-m64/-gstabs} pch.exp' > Ok for trunk? I'll add reversion of this reversion to the 4.9 queued patches > PR. That looks just like the patch I have here. Yet, I'm still seeing failures: Running target unix/-m32/-gstabs Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /home/gcc/GIT/gcc/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /home/gcc/GIT/gcc/gcc/testsuite/gcc.dg/pch/pch.exp ... FAIL: gcc.dg/pch/decl-3.c -O0 -g assembly comparison FAIL: gcc.dg/pch/decl-3.c -O0 assembly comparison FAIL: gcc.dg/pch/decl-3.c -O1 assembly comparison FAIL: gcc.dg/pch/decl-3.c -O2 assembly comparison FAIL: gcc.dg/pch/decl-3.c -O3 -fomit-frame-pointer assembly comparison FAIL: gcc.dg/pch/decl-3.c -O3 -g assembly comparison FAIL: gcc.dg/pch/decl-3.c -Os assembly comparison FAIL: gcc.dg/pch/decl-4.c -O0 -g assembly comparison FAIL: gcc.dg/pch/decl-4.c -O0 assembly comparison FAIL: gcc.dg/pch/decl-4.c -O1 assembly comparison FAIL: gcc.dg/pch/decl-4.c -O2 assembly comparison FAIL: gcc.dg/pch/decl-4.c -O3 -fomit-frame-pointer assembly comparison FAIL: gcc.dg/pch/decl-4.c -O3 -g assembly comparison FAIL: gcc.dg/pch/decl-4.c -Os assembly comparison [ ... ] Can you double-check your testing output? Jeff
On Wed, Feb 13, 2013 at 11:23:24AM -0700, Jeff Law wrote: > On 02/13/13 08:54, Jakub Jelinek wrote: > That looks just like the patch I have here. Yet, I'm still seeing failures: > > Running target unix/-m32/-gstabs > Using /usr/share/dejagnu/baseboards/unix.exp as board description > file for target. > Using /usr/share/dejagnu/config/unix.exp as generic interface file > for target. > Using /home/gcc/GIT/gcc/gcc/testsuite/config/default.exp as > tool-and-target-specific interface file. > Running /home/gcc/GIT/gcc/gcc/testsuite/gcc.dg/pch/pch.exp ... > FAIL: gcc.dg/pch/decl-3.c -O0 -g assembly comparison > FAIL: gcc.dg/pch/decl-3.c -O0 assembly comparison > FAIL: gcc.dg/pch/decl-3.c -O1 assembly comparison > FAIL: gcc.dg/pch/decl-3.c -O2 assembly comparison > FAIL: gcc.dg/pch/decl-3.c -O3 -fomit-frame-pointer assembly comparison > FAIL: gcc.dg/pch/decl-3.c -O3 -g assembly comparison > FAIL: gcc.dg/pch/decl-3.c -Os assembly comparison > FAIL: gcc.dg/pch/decl-4.c -O0 -g assembly comparison > FAIL: gcc.dg/pch/decl-4.c -O0 assembly comparison > FAIL: gcc.dg/pch/decl-4.c -O1 assembly comparison > FAIL: gcc.dg/pch/decl-4.c -O2 assembly comparison > FAIL: gcc.dg/pch/decl-4.c -O3 -fomit-frame-pointer assembly comparison > FAIL: gcc.dg/pch/decl-4.c -O3 -g assembly comparison > FAIL: gcc.dg/pch/decl-4.c -Os assembly comparison > [ ... ] > > Can you double-check your testing output? Yes, I've double checked it. Fresh trunk, got all of gcc.dg/pch/{decl-{3,4},struct-1,system-1,valid-1}.c failures for -m32/-gstabs as well as -m64/-gstabs, both with gcc that has #define HAVE_GAS_CFI_DIRECTIVE {0,1} in auto-host.h. Applying the patch cured all of those failures, except for valid-1.c (which is fine, as that test assumes no -g* switches be present by default). Jakub
On Wed, Feb 13, 2013 at 4:54 PM, Jakub Jelinek wrote: > Hi! > > As agreed on in the PR, here is the revertion of 3 commits, so that > PCH works again for -gstabs and other debug info formats for 4.8 > release. For 4.9 we should either remove support for anything non-DWARF, or > hope somebody steps up and fixes dbxout.c etc. not to emit debug info right > away, but queue it till end of compilation. Hello, I'd still like to propose deprecating all stabs support for GCC 4.8 and remove it for GCC 4.9 (i.e. dbxout, sdbout, xcoffout). It's not a very useful debug info format, after all. The only argument against DWARF, that it is so much larger than stabs, is something I haven't been able to reproduce (see http://sourceware.org/ml/binutils/2013-01/msg00221.html and http://sourceware.org/ml/binutils/2013-01/msg00239.html). DWARF compression via dwz, and debug-fission will improve things even further. An important question is of course: Who still *needs* stabs? If there are important platforms that need stabs support to continue to work, then deprecating is probably not a realistic option yet... The list of platforms that are IMHO blockers rights now, with possible solutions for GCC 4.9, are: * hppa2.0w-hp-hpux11.11 - no solution immediately available * powerpc-ibm-aix* - only support AIX7 and later -> deprecate AIX6 and older in GCC 4.8 * ix86-*-openbsd2.*, ix86-*openbsd3.[0123] - OpenBSD 3.3 was released in May 2003 -> deprecate for GCC 4.8 * m68k*-*-openbsd - port has seen no active maintenance, and has no test results posted, ever -> deprecate for GCC 4.8 * pdp11-*-* - toy port -> default to DEBUG_NONE * ix86-*-interix* - no solution immediately available, and no-one listed in MAINTAINERS to ask for help, so maybe Doug can say something about this one? Platforms that support DWARF2+ but currently have another default preferred debug info type, would be changed to default to DWARF2+. So older AIX and 32-bits HPUX are the only real problem cases. Ciao! Steven All GCC 4.8 primary platforms support DWARF2+, and AFAICT they all have it as their PREFERRED_DEBUGGING_TYPE (including freebsd): * arm-linux-gnueabi * i386-unknown-freebsd * i686-pc-linux-gnu * mipsisa64-elf * powerpc64-unknown-linux-gnu * sparc-sun-solaris2.10 * x86_64-unknown-linux-gnu Most of the above also include other debug info types by default, but DWARF2+ is the default. For the secondary platforms list things are not so simple. Some of them have a non-DWARF PREFERRED_DEBUGGING_TYPE by default, and some only conditionally (old configurations): * hppa2.0w-hp-hpux11.11 -> DBX_DEBUGGING_INFO For 32-bits only, but that's the most common subtarget. According to Dave, it should be possible to add DRAWF2+ support: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117#c14 Perhaps Dave can explain what would have to be done to move this platform to DWARF2...? * powerpc-ibm-aix7.1.0.0 -> XCOFF_DEBUGGING_INFO I think this is for historical reasons. AIX7 has DWARF support, but it looks like that's not yet implemented in GCC. Older AIX do not support DWARF, AFAICT (David E.?). * i686-apple-darwin -> DBX_DEBUGGING_INFO MacOSX10.4, 32-bits (darwin8). All 64bits and darwin9+ prefer DWARF2. * i686-pc-cygwin, i686-mingw32 -> DBX_DEBUGGING_INFO With binutils 2.16 and later, DWARF2_DEBUGGING_INFO is the default: http://sourceware.org/ml/binutils/2004-04/msg00327.html http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01885.html http://cygwin.com/ml/cygwin/2006-06/msg00865.html * s390x-linux-gnu -> DWARF2_DEBUGGING_INFO Other platforms that support DWARF2+ and have it as the preferred type: * *-*-elf* via: config/elfos.h:#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG This is practically all ELF platforms. A few target headers redefine PREFERRED_DEBUGGING_TYPE, usually to DWARF2_DEBUG again... Exceptions are microblaze*-*-rtems*, microblaze*-*-elf* * tic6x-*-*, ix86-*-nto-qnx* via: config/tm-dwarf2.h:#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG * *-*-vxworks* via: config/vx-common.h:#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG * alpha*-dec-*vms* via: config/alpha/vms.h:#define PREFERRED_DEBUGGING_TYPE VMS_AND_DWARF2_DEBUG * hppa*64*-*-hpux11* via: config/pa/pa64-hpux.h:#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG Other platforms that support DWARF2+ but prefer another debug info type by default: * rx-*-elf* if using TARGET_AS100_SYNTAX, via: config/rx/rx.h:#define PREFERRED_DEBUGGING_TYPE (TARGET_AS100_SYNTAX \ config/rx/rx.h: ? DBX_DEBUG : DWARF2_DEBUG) * avr-*-* includes elfos.h but changes preffered debug info type via: config/avr/elf.h:#define PREFERRED_DEBUGGING_TYPE DBX_DEBUG * powerpc-*-lynxos*, ix86-*-lynxos* include elfos.h but change the preffered debug info type via: config/lynx.h:# define PREFERRED_DEBUGGING_TYPE DBX_DEBUG * ix86-pc-msdosdjgpp*, supports DWARF2+ via: config/i386/djgpp.h:#define DWARF2_DEBUGGING_INFO 1 but picks up its preferred debug info via: config/dbxcoff.h:#define PREFERRED_DEBUGGING_TYPE SDB_DEBUG * mn10300-*-*, v850*-*-* if configured --with-stabs, via config/dbx.h:#define PREFERRED_DEBUGGING_TYPE DBX_DEBUG Targets that do not support DWARF2+: * ix86-*-openbsd2.*, ix86-*openbsd3.[0123] * m68k*-*-openbsd via config/m68k/openbsd.h:#define DBX_DEBUGGING_INFO 1 and no other files included that define another debug info type. * pdp11-*-*: config/pdp11/pdp11.h:#define DBX_DEBUGGING_INFO * ix86-*-interix* via: config/i386/i386-interix.h:#define DBX_DEBUGGING_INFO 1 config/i386/i386-interix.h:#define SDB_DEBUGGING_INFO 1 config/i386/i386-interix.h:#define PREFERRED_DEBUGGING_TYPE DBX_DEBUG and picks up nothing else from other header files. Unknown platforms: * config/arm/coff.h:#define PREFERRED_DEBUGGING_TYPE DBX_DEBUG Does any platform use this file?
The AIX system supports DWARF debugging, but GCC does not generate it on AIX and GDB does not consume it on AIX. There is no way that I will allow experimental DWARF support to be enabled at the same time STABS support is removed. This is a non-starter. If you want to disable PCH on STABS systems on just AIX, that is fine. Thanks, David On Wed, Feb 13, 2013 at 4:12 PM, Steven Bosscher <stevenb.gcc@gmail.com> wrote: > On Wed, Feb 13, 2013 at 4:54 PM, Jakub Jelinek wrote: >> Hi! >> >> As agreed on in the PR, here is the revertion of 3 commits, so that >> PCH works again for -gstabs and other debug info formats for 4.8 >> release. For 4.9 we should either remove support for anything non-DWARF, or >> hope somebody steps up and fixes dbxout.c etc. not to emit debug info right >> away, but queue it till end of compilation. > > > Hello, > > I'd still like to propose deprecating all stabs support for GCC 4.8 and > remove it for GCC 4.9 (i.e. dbxout, sdbout, xcoffout). > > It's not a very useful debug info format, after all. The only > argument against DWARF, that it is so much larger than stabs, > is something I haven't been able to reproduce (see > http://sourceware.org/ml/binutils/2013-01/msg00221.html and > http://sourceware.org/ml/binutils/2013-01/msg00239.html). > DWARF compression via dwz, and debug-fission will improve things > even further. > > An important question is of course: Who still *needs* stabs? If there > are important platforms that need stabs support to continue to work, > then deprecating is probably not a realistic option yet... > > The list of platforms that are IMHO blockers rights now, with possible > solutions for GCC 4.9, are: > > * hppa2.0w-hp-hpux11.11 - no solution immediately available > * powerpc-ibm-aix* - only support AIX7 and later > -> deprecate AIX6 and older in GCC 4.8 > * ix86-*-openbsd2.*, ix86-*openbsd3.[0123] - OpenBSD 3.3 was released > in May 2003 -> deprecate for GCC 4.8 > * m68k*-*-openbsd - port has seen no active maintenance, and has no > test results posted, ever -> deprecate for GCC 4.8 > * pdp11-*-* - toy port -> default to DEBUG_NONE > * ix86-*-interix* - no solution immediately available, and no-one > listed in MAINTAINERS to ask for help, so maybe Doug can say > something about this one? > > Platforms that support DWARF2+ but currently have another default > preferred debug info type, would be changed to default to DWARF2+. > > So older AIX and 32-bits HPUX are the only real problem cases. > > Ciao! > Steven > > > > > > > > All GCC 4.8 primary platforms support DWARF2+, and AFAICT they all have > it as their PREFERRED_DEBUGGING_TYPE (including freebsd): > > * arm-linux-gnueabi > * i386-unknown-freebsd > * i686-pc-linux-gnu > * mipsisa64-elf > * powerpc64-unknown-linux-gnu > * sparc-sun-solaris2.10 > * x86_64-unknown-linux-gnu > > Most of the above also include other debug info types by default, but > DWARF2+ is the default. > > For the secondary platforms list things are not so simple. Some of them > have a non-DWARF PREFERRED_DEBUGGING_TYPE by default, and some only > conditionally (old configurations): > > * hppa2.0w-hp-hpux11.11 -> DBX_DEBUGGING_INFO > For 32-bits only, but that's the most common subtarget. > According to Dave, it should be possible to add DRAWF2+ support: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117#c14 > Perhaps Dave can explain what would have to be done to move this > platform to DWARF2...? > > * powerpc-ibm-aix7.1.0.0 -> XCOFF_DEBUGGING_INFO > I think this is for historical reasons. AIX7 has DWARF support, > but it looks like that's not yet implemented in GCC. > Older AIX do not support DWARF, AFAICT (David E.?). > > * i686-apple-darwin -> DBX_DEBUGGING_INFO > MacOSX10.4, 32-bits (darwin8). > All 64bits and darwin9+ prefer DWARF2. > > * i686-pc-cygwin, i686-mingw32 -> DBX_DEBUGGING_INFO > With binutils 2.16 and later, DWARF2_DEBUGGING_INFO is the default: > http://sourceware.org/ml/binutils/2004-04/msg00327.html > http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01885.html > http://cygwin.com/ml/cygwin/2006-06/msg00865.html > > * s390x-linux-gnu -> DWARF2_DEBUGGING_INFO > > > Other platforms that support DWARF2+ and have it as the preferred type: > * *-*-elf* via: > config/elfos.h:#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG > This is practically all ELF platforms. A few target headers redefine > PREFERRED_DEBUGGING_TYPE, usually to DWARF2_DEBUG again... > Exceptions are microblaze*-*-rtems*, microblaze*-*-elf* > * tic6x-*-*, ix86-*-nto-qnx* via: > config/tm-dwarf2.h:#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG > * *-*-vxworks* via: > config/vx-common.h:#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG > * alpha*-dec-*vms* via: > config/alpha/vms.h:#define PREFERRED_DEBUGGING_TYPE VMS_AND_DWARF2_DEBUG > * hppa*64*-*-hpux11* via: > config/pa/pa64-hpux.h:#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG > > > Other platforms that support DWARF2+ but prefer another debug info type > by default: > * rx-*-elf* if using TARGET_AS100_SYNTAX, via: > config/rx/rx.h:#define PREFERRED_DEBUGGING_TYPE (TARGET_AS100_SYNTAX \ > config/rx/rx.h: ? DBX_DEBUG : DWARF2_DEBUG) > * avr-*-* includes elfos.h but changes preffered debug info type via: > config/avr/elf.h:#define PREFERRED_DEBUGGING_TYPE DBX_DEBUG > * powerpc-*-lynxos*, ix86-*-lynxos* include elfos.h but change the > preffered debug info type via: > config/lynx.h:# define PREFERRED_DEBUGGING_TYPE DBX_DEBUG > * ix86-pc-msdosdjgpp*, supports DWARF2+ via: > config/i386/djgpp.h:#define DWARF2_DEBUGGING_INFO 1 > but picks up its preferred debug info via: > config/dbxcoff.h:#define PREFERRED_DEBUGGING_TYPE SDB_DEBUG > * mn10300-*-*, v850*-*-* if configured --with-stabs, via > config/dbx.h:#define PREFERRED_DEBUGGING_TYPE DBX_DEBUG > > > Targets that do not support DWARF2+: > * ix86-*-openbsd2.*, ix86-*openbsd3.[0123] > * m68k*-*-openbsd via config/m68k/openbsd.h:#define DBX_DEBUGGING_INFO 1 > and no other files included that define another debug info type. > * pdp11-*-*: config/pdp11/pdp11.h:#define DBX_DEBUGGING_INFO > * ix86-*-interix* via: > config/i386/i386-interix.h:#define DBX_DEBUGGING_INFO 1 > config/i386/i386-interix.h:#define SDB_DEBUGGING_INFO 1 > config/i386/i386-interix.h:#define PREFERRED_DEBUGGING_TYPE DBX_DEBUG > and picks up nothing else from other header files. > > > Unknown platforms: > * config/arm/coff.h:#define PREFERRED_DEBUGGING_TYPE DBX_DEBUG > Does any platform use this file?
On 02/13/2013 01:12 PM, Steven Bosscher wrote: > * ix86-*-interix* - no solution immediately available, and no-one > listed in MAINTAINERS to ask for help, so maybe Doug can say > something about this one? Microsoft has pulled the plug on Interix, Windows 7 will be the last version of Windows in which it will be available. There's a 64-bit gcc/binutils port to Interix, yet to be contributed, for which the plan is to use Dwarf but the GDB work hasn't been done. I suppose that if does get done, then it would be straightforward to backport Dwarf support to 32bit Interix. So I'm ok with losing stabs in the medium term, or the short term if Interix is the lone hold out. --Doug
On 02/13/13 13:07, Jakub Jelinek wrote: > On Wed, Feb 13, 2013 at 11:23:24AM -0700, Jeff Law wrote: >> On 02/13/13 08:54, Jakub Jelinek wrote: >> That looks just like the patch I have here. Yet, I'm still seeing failures: >> >> Running target unix/-m32/-gstabs >> Using /usr/share/dejagnu/baseboards/unix.exp as board description >> file for target. >> Using /usr/share/dejagnu/config/unix.exp as generic interface file >> for target. >> Using /home/gcc/GIT/gcc/gcc/testsuite/config/default.exp as >> tool-and-target-specific interface file. >> Running /home/gcc/GIT/gcc/gcc/testsuite/gcc.dg/pch/pch.exp ... >> FAIL: gcc.dg/pch/decl-3.c -O0 -g assembly comparison >> FAIL: gcc.dg/pch/decl-3.c -O0 assembly comparison >> FAIL: gcc.dg/pch/decl-3.c -O1 assembly comparison >> FAIL: gcc.dg/pch/decl-3.c -O2 assembly comparison >> FAIL: gcc.dg/pch/decl-3.c -O3 -fomit-frame-pointer assembly comparison >> FAIL: gcc.dg/pch/decl-3.c -O3 -g assembly comparison >> FAIL: gcc.dg/pch/decl-3.c -Os assembly comparison >> FAIL: gcc.dg/pch/decl-4.c -O0 -g assembly comparison >> FAIL: gcc.dg/pch/decl-4.c -O0 assembly comparison >> FAIL: gcc.dg/pch/decl-4.c -O1 assembly comparison >> FAIL: gcc.dg/pch/decl-4.c -O2 assembly comparison >> FAIL: gcc.dg/pch/decl-4.c -O3 -fomit-frame-pointer assembly comparison >> FAIL: gcc.dg/pch/decl-4.c -O3 -g assembly comparison >> FAIL: gcc.dg/pch/decl-4.c -Os assembly comparison >> [ ... ] >> >> Can you double-check your testing output? > > Yes, I've double checked it. Fresh trunk, got all of > gcc.dg/pch/{decl-{3,4},struct-1,system-1,valid-1}.c failures > for -m32/-gstabs as well as -m64/-gstabs, both with gcc > that has #define HAVE_GAS_CFI_DIRECTIVE {0,1} in auto-host.h. > Applying the patch cured all of those failures, except for > valid-1.c (which is fine, as that test assumes no -g* switches > be present by default). I just wiped clean and tried again using your patch and I still see massive failures with -gstabs. I'd like to know why we're getting different results before approving the patch. jeff
On 2013-02-13 3:33 PM, David Edelsohn wrote: > Perhaps Dave can explain what would have to be done to move this > > platform to DWARF2...? > > I had looked at this a bit in the past. I don't think it's that difficult to add DWARF2 support to GCC on hppa. Although we don't support named sections, we can create named subspaces for the dwarf info. More of an issue in my mind is the changes needed to gdb to recognize this support. I agree with David that it might be better to give up pch.
On Wed, Feb 13, 2013 at 10:33 PM, David Edelsohn wrote: > The AIX system supports DWARF debugging, but GCC does not generate it > on AIX and GDB does not consume it on AIX. Is there a description for what has to be done in GCC to enable DWARF with AIX as/ld? E.g. is it required to support the ".dwsect" pseudo? Is there already a plan from someone to make GCC produce DWARF on AIX7? AFAICT, for gcc+gas it should already work with binutils that include the AdaCore patch for DWARF support. But this has apparently not been tested with AIX ld, and there are AdaCore local patches pending. http://sourceware.org/ml/binutils/2011-04/msg00250.html http://www.sourceware.org/ml/gdb/2013-01/msg00030.html > If you want to disable PCH on STABS systems on just AIX, that is fine. This is probably what we'll end up doing, one way or another. That's good enough for the goals I'm trying to achieve in the short term (which means up to 2 years in my case ;-). Ciao! Steven
On 02/13/13 16:17, John David Anglin wrote: > On 2013-02-13 3:33 PM, David Edelsohn wrote: >> Perhaps Dave can explain what would have to be done to move this >>> platform to DWARF2...? >>> > I had looked at this a bit in the past. I don't think it's that > difficult to add DWARF2 support to GCC on hppa. Although we don't > support named sections, we can create named subspaces for the dwarf > info. More of an issue in my mind is the changes needed to gdb to > recognize this support. Given that we can create a subspace for the dwarf bits just like we've got subspaces for stabs bits, it ought to be trivial. The GDB side shouldn't be hard either, just a matter of telling it what subspaces to look for. jeff
On Feb 14, 2013, at 12:26 PM, Steven Bosscher wrote: > On Wed, Feb 13, 2013 at 10:33 PM, David Edelsohn wrote: >> The AIX system supports DWARF debugging, but GCC does not generate it >> on AIX and GDB does not consume it on AIX. > > Is there a description for what has to be done in GCC to enable DWARF > with AIX as/ld? E.g. is it required to support the ".dwsect" pseudo? > Is there already a plan from someone to make GCC produce DWARF on > AIX7? Yes, you need to support the .dwsect pseudo (which is basically a dedicated pseudo like .section, but also includes section length). But note that .dwsect only allows a subset of all dwarf sections. > AFAICT, for gcc+gas it should already work with binutils that include > the AdaCore patch for DWARF support. But this has apparently not been > tested with AIX ld, and there are AdaCore local patches pending. > http://sourceware.org/ml/binutils/2011-04/msg00250.html > http://www.sourceware.org/ml/gdb/2013-01/msg00030.html Yes. Tristan.
On Thu, Feb 14, 2013 at 8:21 AM, Tristan Gingold <gingold@adacore.com> wrote: > > On Feb 14, 2013, at 12:26 PM, Steven Bosscher wrote: > >> On Wed, Feb 13, 2013 at 10:33 PM, David Edelsohn wrote: >>> The AIX system supports DWARF debugging, but GCC does not generate it >>> on AIX and GDB does not consume it on AIX. >> >> Is there a description for what has to be done in GCC to enable DWARF >> with AIX as/ld? E.g. is it required to support the ".dwsect" pseudo? >> Is there already a plan from someone to make GCC produce DWARF on >> AIX7? > > Yes, you need to support the .dwsect pseudo (which is basically a dedicated > pseudo like .section, but also includes section length). > > But note that .dwsect only allows a subset of all dwarf sections. AIX 6 and maybe even AIX 5.3 support DWARF. Because AIX uses XCOFF file format, not ELF, it had to fit DWARF support into the XCOFF design. >> AFAICT, for gcc+gas it should already work with binutils that include >> the AdaCore patch for DWARF support. But this has apparently not been >> tested with AIX ld, and there are AdaCore local patches pending. >> http://sourceware.org/ml/binutils/2011-04/msg00250.html >> http://www.sourceware.org/ml/gdb/2013-01/msg00030.html > > Yes. What is the status of merging Adacore's patches for DWARF support on AIX? Thanks, David
On Thu, Feb 14, 2013 at 2:21 PM, Tristan Gingold wrote: >> Is there a description for what has to be done in GCC to enable DWARF >> with AIX as/ld? E.g. is it required to support the ".dwsect" pseudo? >> Is there already a plan from someone to make GCC produce DWARF on >> AIX7? > > Yes, you need to support the .dwsect pseudo (which is basically a dedicated > pseudo like .section, but also includes section length). AFAIU your binutils patches support DWARF sections with .section instead of .dwsect, right? What is the difficulty with implementing .dwsect for GCC? Ciao! Steven
On Feb 14, 2013, at 3:47 PM, Steven Bosscher wrote: > On Thu, Feb 14, 2013 at 2:21 PM, Tristan Gingold wrote: >>> Is there a description for what has to be done in GCC to enable DWARF >>> with AIX as/ld? E.g. is it required to support the ".dwsect" pseudo? >>> Is there already a plan from someone to make GCC produce DWARF on >>> AIX7? >> >> Yes, you need to support the .dwsect pseudo (which is basically a dedicated >> pseudo like .section, but also includes section length). > > AFAIU your binutils patches support DWARF sections with .section > instead of .dwsect, right? Right. > What is the difficulty with implementing .dwsect for GCC? Shouldn't be very hard, as it is mostly a matter of not emitting section length. Tristan.
>>>>> "Dave" == John David Anglin <dave.anglin@bell.net> writes:
Dave> I had looked at this a bit in the past. I don't think it's that
Dave> difficult to add DWARF2 support
Dave> to GCC on hppa. Although we don't support named sections, we can
Dave> create named subspaces
Dave> for the dwarf info. More of an issue in my mind is the changes needed
Dave> to gdb to recognize
Dave> this support.
I don't think it should be a big problem.
There are other gdb ports that use their own section names for DWARF
sections. In one case I think this the mapping is handled in BFD, but
in another case (XCOFF), it is done in gdb.
Tom
Il 13/02/2013 22:12, Steven Bosscher ha scritto: > On Wed, Feb 13, 2013 at 4:54 PM, Jakub Jelinek wrote: >> Hi! >> >> As agreed on in the PR, here is the revertion of 3 commits, so that >> PCH works again for -gstabs and other debug info formats for 4.8 >> release. For 4.9 we should either remove support for anything non-DWARF, or >> hope somebody steps up and fixes dbxout.c etc. not to emit debug info right >> away, but queue it till end of compilation. > > > Hello, > > I'd still like to propose deprecating all stabs support for GCC 4.8 and > remove it for GCC 4.9 (i.e. dbxout, sdbout, xcoffout). > > It's not a very useful debug info format, after all. The only > argument against DWARF, that it is so much larger than stabs, > is something I haven't been able to reproduce (see > http://sourceware.org/ml/binutils/2013-01/msg00221.html and > http://sourceware.org/ml/binutils/2013-01/msg00239.html). > DWARF compression via dwz, and debug-fission will improve things > even further. > > An important question is of course: Who still *needs* stabs? If there > are important platforms that need stabs support to continue to work, > then deprecating is probably not a realistic option yet... stabs are "needed" to use VTune on Windows. Paolo > The list of platforms that are IMHO blockers rights now, with possible > solutions for GCC 4.9, are: > > * hppa2.0w-hp-hpux11.11 - no solution immediately available > * powerpc-ibm-aix* - only support AIX7 and later > -> deprecate AIX6 and older in GCC 4.8 > * ix86-*-openbsd2.*, ix86-*openbsd3.[0123] - OpenBSD 3.3 was released > in May 2003 -> deprecate for GCC 4.8 > * m68k*-*-openbsd - port has seen no active maintenance, and has no > test results posted, ever -> deprecate for GCC 4.8 > * pdp11-*-* - toy port -> default to DEBUG_NONE > * ix86-*-interix* - no solution immediately available, and no-one > listed in MAINTAINERS to ask for help, so maybe Doug can say > something about this one? > > Platforms that support DWARF2+ but currently have another default > preferred debug info type, would be changed to default to DWARF2+. > > So older AIX and 32-bits HPUX are the only real problem cases. > > Ciao! > Steven > > > > > > > > All GCC 4.8 primary platforms support DWARF2+, and AFAICT they all have > it as their PREFERRED_DEBUGGING_TYPE (including freebsd): > > * arm-linux-gnueabi > * i386-unknown-freebsd > * i686-pc-linux-gnu > * mipsisa64-elf > * powerpc64-unknown-linux-gnu > * sparc-sun-solaris2.10 > * x86_64-unknown-linux-gnu > > Most of the above also include other debug info types by default, but > DWARF2+ is the default. > > For the secondary platforms list things are not so simple. Some of them > have a non-DWARF PREFERRED_DEBUGGING_TYPE by default, and some only > conditionally (old configurations): > > * hppa2.0w-hp-hpux11.11 -> DBX_DEBUGGING_INFO > For 32-bits only, but that's the most common subtarget. > According to Dave, it should be possible to add DRAWF2+ support: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117#c14 > Perhaps Dave can explain what would have to be done to move this > platform to DWARF2...? > > * powerpc-ibm-aix7.1.0.0 -> XCOFF_DEBUGGING_INFO > I think this is for historical reasons. AIX7 has DWARF support, > but it looks like that's not yet implemented in GCC. > Older AIX do not support DWARF, AFAICT (David E.?). > > * i686-apple-darwin -> DBX_DEBUGGING_INFO > MacOSX10.4, 32-bits (darwin8). > All 64bits and darwin9+ prefer DWARF2. > > * i686-pc-cygwin, i686-mingw32 -> DBX_DEBUGGING_INFO > With binutils 2.16 and later, DWARF2_DEBUGGING_INFO is the default: > http://sourceware.org/ml/binutils/2004-04/msg00327.html > http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01885.html > http://cygwin.com/ml/cygwin/2006-06/msg00865.html > > * s390x-linux-gnu -> DWARF2_DEBUGGING_INFO > > > Other platforms that support DWARF2+ and have it as the preferred type: > * *-*-elf* via: > config/elfos.h:#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG > This is practically all ELF platforms. A few target headers redefine > PREFERRED_DEBUGGING_TYPE, usually to DWARF2_DEBUG again... > Exceptions are microblaze*-*-rtems*, microblaze*-*-elf* > * tic6x-*-*, ix86-*-nto-qnx* via: > config/tm-dwarf2.h:#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG > * *-*-vxworks* via: > config/vx-common.h:#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG > * alpha*-dec-*vms* via: > config/alpha/vms.h:#define PREFERRED_DEBUGGING_TYPE VMS_AND_DWARF2_DEBUG > * hppa*64*-*-hpux11* via: > config/pa/pa64-hpux.h:#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG > > > Other platforms that support DWARF2+ but prefer another debug info type > by default: > * rx-*-elf* if using TARGET_AS100_SYNTAX, via: > config/rx/rx.h:#define PREFERRED_DEBUGGING_TYPE (TARGET_AS100_SYNTAX \ > config/rx/rx.h: ? DBX_DEBUG : DWARF2_DEBUG) > * avr-*-* includes elfos.h but changes preffered debug info type via: > config/avr/elf.h:#define PREFERRED_DEBUGGING_TYPE DBX_DEBUG > * powerpc-*-lynxos*, ix86-*-lynxos* include elfos.h but change the > preffered debug info type via: > config/lynx.h:# define PREFERRED_DEBUGGING_TYPE DBX_DEBUG > * ix86-pc-msdosdjgpp*, supports DWARF2+ via: > config/i386/djgpp.h:#define DWARF2_DEBUGGING_INFO 1 > but picks up its preferred debug info via: > config/dbxcoff.h:#define PREFERRED_DEBUGGING_TYPE SDB_DEBUG > * mn10300-*-*, v850*-*-* if configured --with-stabs, via > config/dbx.h:#define PREFERRED_DEBUGGING_TYPE DBX_DEBUG > > > Targets that do not support DWARF2+: > * ix86-*-openbsd2.*, ix86-*openbsd3.[0123] > * m68k*-*-openbsd via config/m68k/openbsd.h:#define DBX_DEBUGGING_INFO 1 > and no other files included that define another debug info type. > * pdp11-*-*: config/pdp11/pdp11.h:#define DBX_DEBUGGING_INFO > * ix86-*-interix* via: > config/i386/i386-interix.h:#define DBX_DEBUGGING_INFO 1 > config/i386/i386-interix.h:#define SDB_DEBUGGING_INFO 1 > config/i386/i386-interix.h:#define PREFERRED_DEBUGGING_TYPE DBX_DEBUG > and picks up nothing else from other header files. > > > Unknown platforms: > * config/arm/coff.h:#define PREFERRED_DEBUGGING_TYPE DBX_DEBUG > Does any platform use this file? >
--- gcc/toplev.c.jj 2013-02-13 09:29:16.197757222 +0100 +++ gcc/toplev.c 2013-02-13 11:34:38.855800182 +0100 @@ -912,7 +912,7 @@ init_asm_output (const char *name) if (!strcmp (asm_file_name, "-")) asm_out_file = stdout; else - asm_out_file = fopen (asm_file_name, "w"); + asm_out_file = fopen (asm_file_name, "w+b"); if (asm_out_file == 0) fatal_error ("can%'t open %s for writing: %m", asm_file_name); } --- gcc/c-family/c-pch.c.jj 2013-02-13 09:29:16.065757956 +0100 +++ gcc/c-family/c-pch.c 2013-02-13 11:34:45.552761549 +0100 @@ -25,6 +25,7 @@ along with GCC; see the file COPYING3. #include "tree.h" #include "flags.h" #include "c-common.h" +#include "output.h" /* for asm_out_file */ #include "debug.h" #include "c-pragma.h" #include "ggc.h" @@ -67,11 +68,19 @@ struct c_pch_validity size_t target_data_length; }; +struct c_pch_header +{ + unsigned long asm_size; +}; + #define IDENT_LENGTH 8 /* The file we'll be writing the PCH to. */ static FILE *pch_outfile; +/* The position in the assembler output file when pch_init was called. */ +static long asm_file_startpos; + static const char *get_ident (void); /* Compute an appropriate 8-byte magic number for the PCH file, so that @@ -83,7 +92,7 @@ static const char * get_ident (void) { static char result[IDENT_LENGTH]; - static const char templ[] = "gpch.014"; + static const char templ[] = "gpch.013"; static const char c_language_chars[] = "Co+O"; memcpy (result, templ, IDENT_LENGTH); @@ -97,7 +106,9 @@ get_ident (void) static bool pch_ready_to_save_cpp_state = false; /* Prepare to write a PCH file, if one is being written. This is - called at the start of compilation. */ + called at the start of compilation. + + Also, print out the executable checksum if -fverbose-asm is in effect. */ void pch_init (void) @@ -107,6 +118,15 @@ pch_init (void) void *target_validity; static const char partial_pch[] = "gpcWrite"; +#ifdef ASM_COMMENT_START + if (flag_verbose_asm) + { + fprintf (asm_out_file, "%s ", ASM_COMMENT_START); + c_common_print_pch_checksum (asm_out_file); + fputc ('\n', asm_out_file); + } +#endif + if (!pch_file) return; @@ -136,6 +156,14 @@ pch_init (void) || fwrite (target_validity, v.target_data_length, 1, f) != 1) fatal_error ("can%'t write to %s: %m", pch_file); + /* We need to be able to re-read the output. */ + /* The driver always provides a valid -o option. */ + if (asm_file_name == NULL + || strcmp (asm_file_name, "-") == 0) + fatal_error ("%qs is not a valid output file", asm_file_name); + + asm_file_startpos = ftell (asm_out_file); + /* Let the debugging format deal with the PCHness. */ (*debug_hooks->handle_pch) (0); @@ -172,6 +200,11 @@ pch_cpp_save_state (void) void c_common_write_pch (void) { + char *buf; + long asm_file_end; + long written; + struct c_pch_header h; + timevar_push (TV_PCH_SAVE); targetm.prepare_pch_save (); @@ -180,6 +213,34 @@ c_common_write_pch (void) cpp_write_pch_deps (parse_in, pch_outfile); + asm_file_end = ftell (asm_out_file); + h.asm_size = asm_file_end - asm_file_startpos; + + if (fwrite (&h, sizeof (h), 1, pch_outfile) != 1) + fatal_error ("can%'t write %s: %m", pch_file); + + buf = XNEWVEC (char, 16384); + + if (fseek (asm_out_file, asm_file_startpos, SEEK_SET) != 0) + fatal_error ("can%'t seek in %s: %m", asm_file_name); + + for (written = asm_file_startpos; written < asm_file_end; ) + { + long size = asm_file_end - written; + if (size > 16384) + size = 16384; + if (fread (buf, size, 1, asm_out_file) != 1) + fatal_error ("can%'t read %s: %m", asm_file_name); + if (fwrite (buf, size, 1, pch_outfile) != 1) + fatal_error ("can%'t write %s: %m", pch_file); + written += size; + } + free (buf); + /* asm_out_file can be written afterwards, so fseek to clear + _IOREAD flag. */ + if (fseek (asm_out_file, 0, SEEK_END) != 0) + fatal_error ("can%'t seek in %s: %m", asm_file_name); + gt_pch_save (pch_outfile); timevar_push (TV_PCH_CPP_SAVE); @@ -341,6 +402,7 @@ c_common_read_pch (cpp_reader *pfile, co int fd, const char *orig_name ATTRIBUTE_UNUSED) { FILE *f; + struct c_pch_header h; struct save_macro_data *smd; expanded_location saved_loc; bool saved_trace_includes; @@ -357,6 +419,38 @@ c_common_read_pch (cpp_reader *pfile, co cpp_get_callbacks (parse_in)->valid_pch = NULL; + if (fread (&h, sizeof (h), 1, f) != 1) + { + cpp_errno (pfile, CPP_DL_ERROR, "reading"); + fclose (f); + goto end; + } + + if (!flag_preprocess_only) + { + unsigned long written; + char * buf = XNEWVEC (char, 16384); + + for (written = 0; written < h.asm_size; ) + { + long size = h.asm_size - written; + if (size > 16384) + size = 16384; + if (fread (buf, size, 1, f) != 1 + || fwrite (buf, size, 1, asm_out_file) != 1) + cpp_errno (pfile, CPP_DL_ERROR, "reading"); + written += size; + } + free (buf); + } + else + { + /* If we're preprocessing, don't write to a NULL + asm_out_file. */ + if (fseek (f, h.asm_size, SEEK_CUR) != 0) + cpp_errno (pfile, CPP_DL_ERROR, "seeking"); + } + /* Save the location and then restore it after reading the PCH. */ saved_loc = expand_location (line_table->highest_line); saved_trace_includes = line_table->trace_includes; @@ -435,3 +529,14 @@ c_common_pch_pragma (cpp_reader *pfile, close (fd); } +/* Print out executable_checksum[]. */ + +void +c_common_print_pch_checksum (FILE *f) +{ + int i; + fputs ("Compiler executable checksum: ", f); + for (i = 0; i < 16; i++) + fprintf (f, "%02x", executable_checksum[i]); + putc ('\n', f); +} --- gcc/c-family/c-opts.c.jj 2013-02-13 09:29:16.110757723 +0100 +++ gcc/c-family/c-opts.c 2013-02-13 11:34:45.551761562 +0100 @@ -999,13 +999,7 @@ c_common_init (void) cpp_init_iconv (parse_in); if (version_flag) - { - int i; - fputs ("Compiler executable checksum: ", stderr); - for (i = 0; i < 16; i++) - fprintf (stderr, "%02x", executable_checksum[i]); - putc ('\n', stderr); - } + c_common_print_pch_checksum (stderr); /* Has to wait until now so that cpplib has its hash table. */ init_pragma (); --- gcc/c-family/c-common.h.jj 2013-02-13 09:29:16.152757462 +0100 +++ gcc/c-family/c-common.h 2013-02-13 11:34:45.551761562 +0100 @@ -1011,6 +1011,7 @@ extern void c_common_read_pch (cpp_reade extern void c_common_write_pch (void); extern void c_common_no_more_pch (void); extern void c_common_pch_pragma (cpp_reader *pfile, const char *); +extern void c_common_print_pch_checksum (FILE *f); /* In *-checksum.c */ extern const unsigned char executable_checksum[16];
Hi! As agreed on in the PR, here is the revertion of 3 commits, so that PCH works again for -gstabs and other debug info formats for 4.8 release. For 4.9 we should either remove support for anything non-DWARF, or hope somebody steps up and fixes dbxout.c etc. not to emit debug info right away, but queue it till end of compilation. Bootstrapped/regtested on x86_64-linux and i686-linux, additionally tested with make check RUNTESTFLAGS='--target_board=unix\{-m32,-m32/-gstabs,-m64,-m64/-gstabs} pch.exp' Ok for trunk? I'll add reversion of this reversion to the 4.9 queued patches PR. 2013-02-13 Jakub Jelinek <jakub@redhat.com> PR pch/54117 Revert 2012-07-14 Steven Bosscher <steven@gcc.gnu.org> * toplev.c (init_asm_output): Open asm_out_file in 'w' mode. * c-pch.c (CHECK_NO_ASM_OUT_DURING_PCH): Do not define. Remove code conditional on it. 2012-07-01 Uros Bizjak <ubizjak@gmail.com> * c-pch.c (c_common_write_pch): Remove unused variables. 2012-06-21 Steven Bosscher <steven@gcc.gnu.org> * c-common.h (c_common_print_pch_checksum): Remove. * c-pch.c: Do not include output.h. (CHECK_NO_ASM_OUT_DURING_PCH): Define and add FIXME. (asm_out_file): Define iff CHECK_NO_ASM_OUT_DURING_PCH isdefined. (asm_file_startpos): Define iff CHECK_NO_ASM_OUT_DURING_PCH is defined. (struct c_pch_header): Remove. (get_ident): Update gpch version. (pch_init): Do not print executable_checksum to asm_out_file. Do not fail if there is no asm_out_file to read back from. Set asm_file_startpos only if CHECK_NO_ASM_OUT_DURING_PCH is defined. (c_common_write_pch): Verify that nothing was written to asm_out_file since pch_init was called. Do not write a c_pch_header, and do not copy from asm_out_file to the PCH. (c_common_read_pch): Do not read a c_pch_header, and do not restore the content of asm_out_file from the PCH. (c_common_print_pch_checksum): Remove. * c-opts.c (c_common_init): Print out executable_checksum directly. Jakub