Patchwork Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

login
register
mail settings
Submitter Jakub Jelinek
Date Feb. 13, 2013, 3:54 p.m.
Message ID <20130213155423.GW4385@tucnak.redhat.com>
Download mbox | patch
Permalink /patch/220179/
State New
Headers show

Comments

Jakub Jelinek - Feb. 13, 2013, 3:54 p.m.
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
Jeff Law - Feb. 13, 2013, 6:23 p.m.
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
Jakub Jelinek - Feb. 13, 2013, 8:07 p.m.
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
Steven Bosscher - Feb. 13, 2013, 9:12 p.m.
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?
David Edelsohn - Feb. 13, 2013, 9:33 p.m.
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?
Douglas B Rupp - Feb. 13, 2013, 9:41 p.m.
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
Jeff Law - Feb. 13, 2013, 10:06 p.m.
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
John David Anglin - Feb. 13, 2013, 11:17 p.m.
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.
Steven Bosscher - Feb. 14, 2013, 11:26 a.m.
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
Jeff Law - Feb. 14, 2013, 12:24 p.m.
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
Tristan Gingold - Feb. 14, 2013, 1:21 p.m.
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.
David Edelsohn - Feb. 14, 2013, 1:27 p.m.
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
Steven Bosscher - Feb. 14, 2013, 2:47 p.m.
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
Tristan Gingold - Feb. 14, 2013, 3:30 p.m.
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.
Tom Tromey - Feb. 14, 2013, 9:15 p.m.
>>>>> "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
Paolo Bonzini - Feb. 19, 2013, 8:57 p.m.
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?
>

Patch

--- 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];