[PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Jakub Jelinek]

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.

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


	Jakub

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Jeff Law]

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

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Jakub Jelinek]

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

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Steven Bosscher]

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?

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[David Edelsohn]

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?

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Douglas B Rupp]

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

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Jeff Law]

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

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[John David Anglin]

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.

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Steven Bosscher]

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

On Thu, Feb 14, 2013 at 12:17 AM, 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.
>
> I agree with David that it might be better to give up pch.

That'd be a really a good start.

How about something like the attached patch for trunk?
Tested on powerpc64-linux pch.exp with -gstabs.

Ciao!
Steven

c-family/
        * c-opts.c (c_common_handle_option): Warn that pre-compiled headers
        with debug formats other than DWARF are deprecated.

testsuite/
        * lib/dg-pch.exp: Compile the PCH with extra flag -Wno-deprecated.

[-- Attachment #2: deprecate_pch_nondwarf.diff.txt --]
[-- Type: text/plain, Size: 1551 bytes --]

c-family/
	* c-opts.c (c_common_handle_option): Warn that pre-compiled headers
	with debug formats other than DWARF are deprecated.

testsuite/
	* lib/dg-pch.exp: Compile the PCH with extra flag -Wno-deprecated.

Index: c-family/c-opts.c
===================================================================
--- c-family/c-opts.c	(revision 196032)
+++ c-family/c-opts.c	(working copy)
@@ -268,6 +268,10 @@ c_common_handle_option (size_t scode, const char *
       break;
 
     case OPT__output_pch_:
+      if (write_symbols != NO_DEBUG && write_symbols != DWARF2_DEBUG)
+	warning (OPT_Wdeprecated,
+		 "the \"%s\" debug format cannot be used with pre-compiled headers",
+		 debug_type_names[write_symbols]);
       pch_file = arg;
       break;
 
Index: testsuite/lib/dg-pch.exp
===================================================================
--- testsuite/lib/dg-pch.exp	(revision 196032)
+++ testsuite/lib/dg-pch.exp	(working copy)
@@ -39,8 +39,12 @@ proc dg-flags-pch { subdir test otherflags options
 	set dg-do-what-default precompile
 	catch { file_on_host delete "$bname$suffix" }
 	gcc_copy_files "[file rootname $test]${suffix}s" "$bname$suffix"
-	dg-test -keep-output "./$bname$suffix" "$otherflags $flags" ""
 
+	# Suppress -Wdeprecated to allow PCH tests to work with non-DWARF2
+	# debug formats.  Support for such combinations has been deprecated
+	# for GCC 4.8.
+	dg-test -keep-output "./$bname$suffix" "$otherflags $flags -Wno-deprecated" ""
+
 	# For the rest, the default is to compile to .s.
 	set dg-do-what-default compile
 

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Jakub Jelinek]

On Thu, Feb 14, 2013 at 12:41:30AM +0100, Steven Bosscher wrote:
> > I agree with David that it might be better to give up pch.
> 
> That'd be a really a good start.

You can do it with say following patch instead, PCH is just a compile time
optimization, so for -gstabs IMHO it is just fine if we just give up.

--- gcc/c-family/c-opts.c.jj	2013-02-13 23:48:14.000000000 +0100
+++ gcc/c-family/c-opts.c	2013-02-14 00:41:05.325625590 +0100
@@ -943,8 +943,11 @@ c_common_post_options (const char **pfil
 
       /* When writing a PCH file, avoid reading some other PCH file,
 	 because the default address space slot then can't be used
-	 for the output PCH file.  */
-      if (pch_file)
+	 for the output PCH file.  Also, avoid reading PCH files when
+	 debug info in format other than DWARF is requested.  */
+      if (pch_file
+	  || (write_symbols != NO_DEBUG
+	      && write_symbols != DWARF2_DEBUG))
 	c_common_no_more_pch ();
 
       /* Yuk.  WTF is this?  I do know ObjC relies on it somewhere.  */


	Jakub

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Steven Bosscher]

On Thu, Feb 14, 2013 at 12:48 AM, Jakub Jelinek wrote:
> On Thu, Feb 14, 2013 at 12:41:30AM +0100, Steven Bosscher wrote:
>> > I agree with David that it might be better to give up pch.
>>
>> That'd be a really a good start.
>
> You can do it with say following patch instead, PCH is just a compile time
> optimization, so for -gstabs IMHO it is just fine if we just give up.

Does that also provent *writing* a PCH with -gstabs?

The point of making asm_out_file write-only and stop front ends from
writing to it, is to postpone opening asm_out_file to some point as
late as possible. For this to work, attempting to write a PCH must
also be disabled (because of the early stabs output to asm_out_file).

Ciao!
Steven

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Jakub Jelinek]

On Thu, Feb 14, 2013 at 11:19:22AM +0100, Steven Bosscher wrote:
> On Thu, Feb 14, 2013 at 12:48 AM, Jakub Jelinek wrote:
> > On Thu, Feb 14, 2013 at 12:41:30AM +0100, Steven Bosscher wrote:
> >> > I agree with David that it might be better to give up pch.
> >>
> >> That'd be a really a good start.
> >
> > You can do it with say following patch instead, PCH is just a compile time
> > optimization, so for -gstabs IMHO it is just fine if we just give up.
> 
> Does that also provent *writing* a PCH with -gstabs?

No, it prevents *reading* of PCH files with -gstabs, so whatever you write
into the PCH file is uninteresting.  The patch can surely be acompanied
by a patch to warn that writing a PCH file is useless in that case, as in
your patch, though the spot you chose for it is too early.  Consider
./xgcc -B ./ -gstabs -o aa.h.gch aa.h -g0
cc1: warning: the "stabs" debug format cannot be used with pre-compiled headers [-Wdeprecated]
which warns even when the header is actually precompiled without debug info.
If you try to use such PCH file with say
./xgcc -B ./ -gstabs aa.c
it will fail to load PCH because of option mismatch (similarly for -g
created PCH file and non-g user), but if you do
./xgcc -B ./ -gstabs aa.c -g0
there should be no reason why it wouldn't work right, so you shouldn't warn
earlier.
So, IMHO you want to warn at the spot which I've changed in my patch,
add
if (pch_file && (write_symbols != NO_DEBUG && write_symbols != DWARF2_DEBUG))
  warning...
there.
And, of course, pch.exp testsuite won't work if -gstabs etc. is in effect,
because it does those hacks which ensure that if PCH isn't loaded, tests
fail (the original header file isn't available when testing PCH load).
That is not a problem for normal PCH uses, where the headers are available,
but pch.exp would need to be tweaked for it somehow.
Supposedly not do any testing if -g (defaulting to non-dwarf) or -gstabs
etc. are present in the default options (try to pre-compile some short
header first, if that fails with the newly added warning, punt),
drop all torture options using -g in it if such test fails with explicit
-g added from the list of torture options for testing, and perhaps add some
effective target if needed (valid-1.c test?).

	Jakub

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Steven Bosscher]

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

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Jeff Law]

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

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Jeff Law]

On 02/14/13 03:52, Jakub Jelinek wrote:
>
> No, it prevents *reading* of PCH files with -gstabs, so whatever you write
> into the PCH file is uninteresting.  The patch can surely be acompanied
> by a patch to warn that writing a PCH file is useless in that case, as in
> your patch, though the spot you chose for it is too early.  Consider
> ./xgcc -B ./ -gstabs -o aa.h.gch aa.h -g0
[ ... ]
It's a fairly minor point, but I see what you're saying.




> Supposedly not do any testing if -g (defaulting to non-dwarf) or -gstabs
> etc. are present in the default options (try to pre-compile some short
> header first, if that fails with the newly added warning, punt),
> drop all torture options using -g in it if such test fails with explicit
> -g added from the list of torture options for testing, and perhaps add some
> effective target if needed (valid-1.c test?).
I think two tests should be sufficient.  First, compile a simple program 
with -g and verify it generates dwarf2 debug records.  Second verify 
that there aren't any -g<foo> options, unless <foo> is dwarf2.

I'm actually on PTO today/tomorrow, so I won't be able to look further 
at this until Monday.

If someone wants to run with it, my recommendation would be Steven's 
warning patch, moved to the location Jakub suggests so that users know 
stabs+PCH is going away plus a hack to the testsuite suite similar to 
what I outlined above plus something to either suppress creation of the 
pch or suppress reading the PCH in the presence of non-dwarf debug output.

--

Jakub -- presumably the implicit include of stdc-predef.h is what is 
causing the testing differences we were seeing.

Jeff

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Tristan Gingold]

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.

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[David Edelsohn]

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

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Steven Bosscher]

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

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Tristan Gingold]

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.

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Tom Tromey]

>>>>> "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

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]

> >> 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
> 
> What is the status of merging Adacore's patches for DWARF support on AIX?

Sorry, David. I have been meaning to work on that ever since
we talked about it...

I spent some time today isolating the patches. I am currently
testing the patches we wrote for support on AIX 5.3. I then see
a few more patches to extend support to AIX 7.1 - section alignment
constraints, and stuff related to TLS.

Just for anyone who is curious, this is what I am testing.
It is missing the pieces for the other tools such as objdump,
for instance. But I think those can be submitted separately.

It might not apply to HEAD just yet, because I'm going at it
step by step. For those who use git, I applied it on top of:

    commit 889f73fdb5bec852e083f47703f31592ef3ee77b
    Author: Alan Modra <amodra@bigpond.net.au>
    Date:   Thu Oct 18 23:00:04 2012 +0000

        daily update

-- 
Joel

[-- Attachment #2: 0001-AIX-add-DWARF-support.patch --]
[-- Type: text/x-diff, Size: 7626 bytes --]

From dc928a0dbd0e762577c51204b043d6b6f066940d Mon Sep 17 00:00:00 2001
From: Joel Brobecker <brobecker@adacore.com>
Date: Thu, 14 Feb 2013 23:53:25 +0100
Subject: [PATCH] AIX: add DWARF support

        * bfd/coff-rs6000.c (xcoff_dwsect_names): Add .dwframe,
        .dwloc, .dwmacif and .dwmacro.
        * bfd/libxcoff.h (XCOFF_DWSECT_NBR_NAMES): Set to 12.
        * xcofflink.c (xcoff_mark): Mark all debugging symbols.
        (bfd_xcoff_size_dynamic_sections): Mark all debugging sections.
        (xcoff_link_input_bfd): Gah???
        * gas/config/tc-ppc.c (ppc_named_section): Add handling
        of DWARF sections.
---
 bfd/coff-rs6000.c   |    6 ++++-
 bfd/libxcoff.h      |    2 +-
 bfd/xcofflink.c     |   65 +++++++++++++++++++++++++++++---------------------
 gas/config/tc-ppc.c |   29 ++++++++++++++++++++++-
 4 files changed, 72 insertions(+), 30 deletions(-)

diff --git a/bfd/coff-rs6000.c b/bfd/coff-rs6000.c
index 0945aca..9388ce3 100644
--- a/bfd/coff-rs6000.c
+++ b/bfd/coff-rs6000.c
@@ -3916,7 +3916,11 @@ const struct xcoff_dwsect_name xcoff_dwsect_names[] = {
   { SSUBTYP_DWARNGE, ".dwarnge",  TRUE },
   { SSUBTYP_DWABREV, ".dwabrev",  FALSE },
   { SSUBTYP_DWSTR,   ".dwstr",    TRUE },
-  { SSUBTYP_DWRNGES, ".dwrnges",  TRUE }
+  { SSUBTYP_DWRNGES, ".dwrnges",  TRUE },
+  { 0x47000000,      ".dwframe",  TRUE },
+  { 0x47010000,      ".dwloc",    TRUE },
+  { 0x47020000,      ".dwmacif",  FALSE },
+  { 0x47030000,      ".dwmacro",  FALSE }
 };
 
 static const struct xcoff_backend_data_rec bfd_xcoff_backend_data =
diff --git a/bfd/libxcoff.h b/bfd/libxcoff.h
index 53a5e72..7583d5c 100644
--- a/bfd/libxcoff.h
+++ b/bfd/libxcoff.h
@@ -251,7 +251,7 @@ struct xcoff_dwsect_name {
 
 /* Number of entries in the array.  The number is known and public so that user
    can 'extend' this array by index.  */
-#define XCOFF_DWSECT_NBR_NAMES	8
+#define XCOFF_DWSECT_NBR_NAMES	12
 
 /* The dwarf sections array.  */
 extern const struct xcoff_dwsect_name
diff --git a/bfd/xcofflink.c b/bfd/xcofflink.c
index 4adfb17..ad31643 100644
--- a/bfd/xcofflink.c
+++ b/bfd/xcofflink.c
@@ -2902,8 +2902,7 @@ xcoff_mark (struct bfd_link_info *info, asection *sec)
   sec->flags |= SEC_MARK;
 
   if (sec->owner->xvec == info->output_bfd->xvec
-      && coff_section_data (sec->owner, sec) != NULL
-      && xcoff_section_data (sec->owner, sec) != NULL)
+      && coff_section_data (sec->owner, sec) != NULL)
     {
       struct xcoff_link_hash_entry **syms;
       struct internal_reloc *rel, *relend;
@@ -2911,18 +2910,21 @@ xcoff_mark (struct bfd_link_info *info, asection *sec)
       unsigned long i, first, last;
 
       /* Mark all the symbols in this section.  */
-      syms = obj_xcoff_sym_hashes (sec->owner);
-      csects = xcoff_data (sec->owner)->csects;
-      first = xcoff_section_data (sec->owner, sec)->first_symndx;
-      last = xcoff_section_data (sec->owner, sec)->last_symndx;
-      for (i = first; i <= last; i++)
-	if (csects[i] == sec
-	    && syms[i] != NULL
-	    && (syms[i]->flags & XCOFF_MARK) == 0)
-	  {
-	    if (!xcoff_mark_symbol (info, syms[i]))
-	      return FALSE;
-	  }
+      if (xcoff_section_data (sec->owner, sec) != NULL)
+        {
+          syms = obj_xcoff_sym_hashes (sec->owner);
+          csects = xcoff_data (sec->owner)->csects;
+          first = xcoff_section_data (sec->owner, sec)->first_symndx;
+          last = xcoff_section_data (sec->owner, sec)->last_symndx;
+          for (i = first; i <= last; i++)
+            if (csects[i] == sec
+                && syms[i] != NULL
+                && (syms[i]->flags & XCOFF_MARK) == 0)
+              {
+                if (!xcoff_mark_symbol (info, syms[i]))
+                  return FALSE;
+              }
+        }
 
       /* Look through the section relocs.  */
       if ((sec->flags & SEC_RELOC) != 0
@@ -2965,7 +2967,8 @@ xcoff_mark (struct bfd_link_info *info, asection *sec)
 
 	      /* See if this reloc needs to be copied into the .loader
 		 section.  */
-	      if (xcoff_need_ldrel_p (info, rel, h))
+	      if ((sec->flags & SEC_DEBUGGING) == 0
+                  && xcoff_need_ldrel_p (info, rel, h))
 		{
 		  ++xcoff_hash_table (info)->ldrel_count;
 		  if (h != NULL)
@@ -3760,6 +3763,17 @@ bfd_xcoff_size_dynamic_sections (bfd *output_bfd,
 	  if (ldinfo.failed)
 	    goto error_return;
 	}
+      /* Mark all debugging sections.  */
+      for (sub = info->input_bfds; sub != NULL; sub = sub->link_next)
+	{
+	  asection *o;
+
+	  for (o = sub->sections; o != NULL; o = o->next)
+            if ((o->flags & SEC_DEBUGGING) != 0
+                && (o->flags & SEC_MARK) == 0
+                && ! xcoff_mark (info, o))
+              goto error_return;
+        }
       xcoff_sweep (info);
       xcoff_hash_table (info)->gc = TRUE;
     }
@@ -4920,7 +4934,7 @@ xcoff_link_input_bfd (struct xcoff_final_link_info *flinfo,
 
 		      if (indx != -1)
 			irel->r_symndx = indx;
-		      else
+                      else if ((o->flags & SEC_DEBUGGING) == 0)
 			{
 
 			  struct internal_syment *is;
@@ -4933,19 +4947,16 @@ xcoff_link_input_bfd (struct xcoff_final_link_info *flinfo,
 			     this case, but I don't think it's worth it.  */
 			  is = flinfo->internal_syms + r_symndx;
 
-                          if (is->n_sclass != C_DWARF)
-                            {
-                              name = (_bfd_coff_internal_syment_name
-                                      (input_bfd, is, buf));
+                          name = (_bfd_coff_internal_syment_name
+                                  (input_bfd, is, buf));
 
-                              if (name == NULL)
-                                return FALSE;
+                          if (name == NULL)
+                            return FALSE;
 
-                              if (!(*flinfo->info->callbacks->unattached_reloc)
-                                  (flinfo->info, name, input_bfd, o,
-                                   irel->r_vaddr))
-                                return FALSE;
-                            }
+                          if (!(*flinfo->info->callbacks->unattached_reloc)
+                              (flinfo->info, name, input_bfd, o,
+                               irel->r_vaddr))
+                            return FALSE;
 			}
 		    }
 		}
diff --git a/gas/config/tc-ppc.c b/gas/config/tc-ppc.c
index 2820c31..8579c2d 100644
--- a/gas/config/tc-ppc.c
+++ b/gas/config/tc-ppc.c
@@ -3951,7 +3951,34 @@ ppc_named_section (int ignore ATTRIBUTE_UNUSED)
     real_name = ".data[RW]";
   else
     {
-      as_bad (_("the XCOFF file format does not support arbitrary sections"));
+      /* Entries in this array correspond to the ones in
+         xcoff_dwsect_names.  */
+      static const char * const dwarf_sections[XCOFF_DWSECT_NBR_NAMES] = {
+        ".debug_info",
+        ".debug_line",
+        ".debug_pubnames",
+        ".debug_pubtypes",
+        ".debug_aranges",
+        ".debug_abbrev",
+        ".debug_str",
+        ".debug_ranges",
+        ".debug_frame",
+        ".debug_loc",
+        ".debug_macinfo",
+        ".debug_macro", };
+      int i;
+
+      /* Try dwarf sections.  */
+      for (i = 0; i < XCOFF_DWSECT_NBR_NAMES; i++)
+        if (strcmp (user_name, dwarf_sections[i]) == 0)
+          {
+            *input_line_pointer = c;
+            demand_empty_rest_of_line ();
+            ppc_change_debug_section (i, 0);
+            return;
+          }
+
+      as_bad (_("The XCOFF file format does not support arbitrary sections"));
       *input_line_pointer = c;
       ignore_rest_of_line ();
       return;
-- 
1.6.5.rc2

[PATCH] Disable PCH for -g other than dwarf[234] (PR pch/54117, take 2)

[Jakub Jelinek]

On Thu, Feb 14, 2013 at 05:48:57AM -0700, Jeff Law wrote:
> I think two tests should be sufficient.  First, compile a simple
> program with -g and verify it generates dwarf2 debug records.
> Second verify that there aren't any -g<foo> options, unless <foo> is
> dwarf2.
> 
> I'm actually on PTO today/tomorrow, so I won't be able to look
> further at this until Monday.
> 
> If someone wants to run with it, my recommendation would be Steven's
> warning patch, moved to the location Jakub suggests so that users
> know stabs+PCH is going away plus a hack to the testsuite suite
> similar to what I outlined above plus something to either suppress
> creation of the pch or suppress reading the PCH in the presence of
> non-dwarf debug output.

Here is what seems to work for me.
Tested with
make check -j4 -k RUNTESTFLAGS='--target_board=unix\{-m32,-m32/-gstabs,-m64,-m64/-gstabs\} pch.exp'
on x86_64-linux, both with gcc just with this patch and also
this patch + changed PREFERRED_DEBUGGING_TYPE to DBX_DEBUG.
No FAILs at all, tests that wouldn't work because either -gstabs is forced
in the flags from target board or tests that would be compiled with -g
when stabs is the default are UNSUPPORTED.

2013-02-15  Jakub Jelinek  <jakub@redhat.com>
	    Steven Bosscher  <steven@gcc.gnu.org>

	PR pch/54117
	* c-opts.c (c_common_post_options): If debug info is enabled
	and non-dwarf*, refuse to load PCH files and when writing PCH
	file warn.

	* lib/dg-pch.exp (pch-init, pch-finish,
	check_effective_target_pch_supported_debug): New procs.
	(dg-flags-pch): If $pch_unsupported, make tests UNSUPPORTED.
	Likewise if $pch_unsupported_debug and $flags include -g.
	Skip FAILs about missing *.gch file if $pch_unsupported_debug
	and dg-require-effective-target pch_unsupported_debug.
	* g++.dg/pch/pch.exp: Call pch-init and pch-finish.
	* objc.dg/pch/pch.exp: Likewise.
	* gcc.dg/pch/pch.exp: Likewise.
	* gcc.dg/pch/valid-1.c: Add dg-require-effective-target
	pch_unsupported_debug.
	* gcc.dg/pch/valid-1.hs: Likewise.
	* gcc.dg/pch/valid-1b.c: Likewise.
	* gcc.dg/pch/valid-1b.hs: Likewise.

--- gcc/c-family/c-opts.c.jj	2013-02-14 14:45:01.000000000 +0100
+++ gcc/c-family/c-opts.c	2013-02-15 12:44:48.936535118 +0100
@@ -945,6 +945,16 @@ c_common_post_options (const char **pfil
 	 because the default address space slot then can't be used
 	 for the output PCH file.  */
       if (pch_file)
+	{
+	  c_common_no_more_pch ();
+	  /* Only -g0 and -gdwarf* are supported with PCH, for other
+	     debug formats we warn here and refuse to load any PCH files.  */
+	  if (write_symbols != NO_DEBUG && write_symbols != DWARF2_DEBUG)
+	    warning (OPT_Wdeprecated,
+		     "the \"%s\" debug format cannot be used with "
+		     "pre-compiled headers", debug_type_names[write_symbols]);
+	}
+      else if (write_symbols != NO_DEBUG && write_symbols != DWARF2_DEBUG)
 	c_common_no_more_pch ();
 
       /* Yuk.  WTF is this?  I do know ObjC relies on it somewhere.  */
--- gcc/testsuite/lib/dg-pch.exp.jj	2013-01-11 09:02:39.000000000 +0100
+++ gcc/testsuite/lib/dg-pch.exp	2013-02-15 15:45:53.747855529 +0100
@@ -16,8 +16,49 @@
 
 load_lib copy-file.exp
 
+proc pch-init { args } {
+    global pch_unsupported_debug pch_unsupported
+
+    if [info exists pch_unsupported_debug] {
+	error "pch-init: pch_unsupported_debug is not empty as expected"
+    }
+    if [info exists pch_unsupported] {
+	error "pch-init: pch_unsupported is not empty as expected"
+    }
+
+    set result [check_compile pchtest object "int i;" "-g -x c-header"]
+    set pch_unsupported_debug \
+	[regexp "debug format cannot be used with pre-compiled headers" \
+		[lindex $result 0]]
+
+    set pch_unsupported 0
+    if { $pch_unsupported_debug } {
+	verbose -log "pch is unsupported with the debug info format"
+
+	set result [check_compile pchtest object "int i;" "-x c-header"]
+	    set pch_unsupported \
+		[regexp "debug format cannot be used with pre-compiled headers" \
+			[lindex $result 0]]
+    }
+}
+
+proc pch-finish { args } {
+    global pch_unsupported_debug pch_unsupported
+    unset pch_unsupported_debug
+    unset pch_unsupported
+}
+
+proc check_effective_target_pch_supported_debug { } {
+    global pch_unsupported_debug
+    if { $pch_unsupported_debug } {
+	return 0
+    }
+    return 1
+}
+
 proc dg-flags-pch { subdir test otherflags options suffix } {
     global runtests dg-do-what-default
+    global pch_unsupported_debug pch_unsupported
 
     # If we're only testing specific files and this isn't one of them, skip it.
     if ![runtest_file_p $runtests $test] {
@@ -35,6 +76,13 @@ proc dg-flags-pch { subdir test otherfla
     foreach flags $options {
 	verbose "Testing $nshort, $otherflags $flags" 1
 
+	if { $pch_unsupported != 0 \
+	     || ( $pch_unsupported_debug != 0 && [regexp " -g" " $flags"] ) } {
+	    verbose -log "$nshort unsupported because debug format conflicts with PCH"
+	    unsupported "$nshort $flags"
+	    continue
+	}
+
 	# For the header files, the default is to precompile.
 	set dg-do-what-default precompile
 	catch { file_on_host delete "$bname$suffix" }
@@ -78,7 +126,8 @@ proc dg-flags-pch { subdir test otherfla
  		    fail "$nshort $flags assembly comparison"
 		}
 	    }
-	} else {
+	} elseif { $pch_unsupported_debug == 0 \
+		   || [llength [grep $test "{\[ \t\]\+dg-require-effective-target\[ \t\]\+pch_supported_debug\[ \t\]\+.*\[ \t\]\+}"]] > 0 } {
 	    verbose -log "pch file '$bname$suffix.gch' missing"
 	    fail "$nshort $flags"
 	    if { !$have_errs } {
--- gcc/testsuite/g++.dg/pch/pch.exp.jj	2013-01-11 09:02:44.000000000 +0100
+++ gcc/testsuite/g++.dg/pch/pch.exp	2013-02-15 14:53:03.517106464 +0100
@@ -23,6 +23,7 @@ load_lib dg-pch.exp
 
 # Initialize `dg'.
 dg-init
+pch-init
 
 set old_dg_do_what_default "${dg-do-what-default}"
 
@@ -36,4 +37,5 @@ foreach test [lsort [glob -nocomplain $s
 set dg-do-what-default "$old_dg_do_what_default"
 
 # All done.
+pch-finish
 dg-finish
--- gcc/testsuite/objc.dg/pch/pch.exp.jj	2013-01-11 09:02:44.000000000 +0100
+++ gcc/testsuite/objc.dg/pch/pch.exp	2013-02-15 14:53:30.063951051 +0100
@@ -24,8 +24,8 @@ load_lib torture-options.exp
 
 # Initialize `dg'.
 dg-init
-
 torture-init
+pch-init
 
 set-torture-options $DG_TORTURE_OPTIONS
 
@@ -59,5 +59,6 @@ if [istarget "*-*-darwin*" ] {
 set dg-do-what-default "$old_dg_do_what_default"
 
 # All done.
+pch-finish
 torture-finish
 dg-finish
--- gcc/testsuite/gcc.dg/pch/pch.exp.jj	2013-01-11 09:02:42.000000000 +0100
+++ gcc/testsuite/gcc.dg/pch/pch.exp	2013-02-15 14:11:27.053896809 +0100
@@ -26,6 +26,7 @@ load_lib torture-options.exp
 dg-init
 torture-init
 set-torture-options $DG_TORTURE_OPTIONS
+pch-init
 
 set old_dg_do_what_default "${dg-do-what-default}"
 
@@ -59,5 +60,6 @@ file delete $testh
 set dg-do-what-default "$old_dg_do_what_default"
 
 # All done.
+pch-finish
 torture-finish
 dg-finish
--- gcc/testsuite/gcc.dg/pch/valid-1.c.jj	2009-06-08 11:53:48.000000000 +0200
+++ gcc/testsuite/gcc.dg/pch/valid-1.c	2013-02-15 15:19:44.124833259 +0100
@@ -1,3 +1,4 @@
+/* { dg-require-effective-target pch_supported_debug } */
 /* { dg-options "-I. -Winvalid-pch -g" } */
 
 #include "valid-1.h"/* { dg-warning "created with -gnone, but used with -g" } */
--- gcc/testsuite/gcc.dg/pch/valid-1.hs.jj	2008-09-05 12:54:26.000000000 +0200
+++ gcc/testsuite/gcc.dg/pch/valid-1.hs	2013-02-15 15:19:50.686794340 +0100
@@ -1,3 +1,4 @@
+/* { dg-require-effective-target pch_supported_debug } */
 /* { dg-options "-I. -Winvalid-pch -g0" } */
 
 extern int x;
--- gcc/testsuite/gcc.dg/pch/valid-1b.c.jj	2008-09-05 12:54:26.000000000 +0200
+++ gcc/testsuite/gcc.dg/pch/valid-1b.c	2013-02-15 15:19:55.935763631 +0100
@@ -1,3 +1,4 @@
+/* { dg-require-effective-target pch_supported_debug } */
 /* { dg-options "-I. -Winvalid-pch -g0" } */
 
 #include "valid-1b.h"
--- gcc/testsuite/gcc.dg/pch/valid-1b.hs.jj	2008-09-05 12:54:26.000000000 +0200
+++ gcc/testsuite/gcc.dg/pch/valid-1b.hs	2013-02-15 15:20:02.214727794 +0100
@@ -1,3 +1,4 @@
+/* { dg-require-effective-target pch_supported_debug } */
 /* { dg-options "-I. -Winvalid-pch -g" } */
 
 extern int x;


	Jakub

Re: [PATCH] Disable PCH for -g other than dwarf[234] (PR pch/54117, take 2)

[John David Anglin]

The patch successfully disables stabs+PCH on hppa2.0w-hp-hpux11.11 and 
fixes the
testsuite regressions.  Also tested on hppa64-hp-hpux11.11 with no 
regressions.

On 2013-02-15 9:08 AM, Jakub Jelinek wrote:
> On Thu, Feb 14, 2013 at 05:48:57AM -0700, Jeff Law wrote:
>> I think two tests should be sufficient.  First, compile a simple
>> program with -g and verify it generates dwarf2 debug records.
>> Second verify that there aren't any -g<foo> options, unless <foo> is
>> dwarf2.
>>
>> I'm actually on PTO today/tomorrow, so I won't be able to look
>> further at this until Monday.
>>
>> If someone wants to run with it, my recommendation would be Steven's
>> warning patch, moved to the location Jakub suggests so that users
>> know stabs+PCH is going away plus a hack to the testsuite suite
>> similar to what I outlined above plus something to either suppress
>> creation of the pch or suppress reading the PCH in the presence of
>> non-dwarf debug output.
> Here is what seems to work for me.
> Tested with
> make check -j4 -k RUNTESTFLAGS='--target_board=unix\{-m32,-m32/-gstabs,-m64,-m64/-gstabs\} pch.exp'
> on x86_64-linux, both with gcc just with this patch and also
> this patch + changed PREFERRED_DEBUGGING_TYPE to DBX_DEBUG.
> No FAILs at all, tests that wouldn't work because either -gstabs is forced
> in the flags from target board or tests that would be compiled with -g
> when stabs is the default are UNSUPPORTED.
>
> 2013-02-15  Jakub Jelinek  <jakub@redhat.com>
> 	    Steven Bosscher  <steven@gcc.gnu.org>
>
> 	PR pch/54117
> 	* c-opts.c (c_common_post_options): If debug info is enabled
> 	and non-dwarf*, refuse to load PCH files and when writing PCH
> 	file warn.
>
> 	* lib/dg-pch.exp (pch-init, pch-finish,
> 	check_effective_target_pch_supported_debug): New procs.
> 	(dg-flags-pch): If $pch_unsupported, make tests UNSUPPORTED.
> 	Likewise if $pch_unsupported_debug and $flags include -g.
> 	Skip FAILs about missing *.gch file if $pch_unsupported_debug
> 	and dg-require-effective-target pch_unsupported_debug.
> 	* g++.dg/pch/pch.exp: Call pch-init and pch-finish.
> 	* objc.dg/pch/pch.exp: Likewise.
> 	* gcc.dg/pch/pch.exp: Likewise.
> 	* gcc.dg/pch/valid-1.c: Add dg-require-effective-target
> 	pch_unsupported_debug.
> 	* gcc.dg/pch/valid-1.hs: Likewise.
> 	* gcc.dg/pch/valid-1b.c: Likewise.
> 	* gcc.dg/pch/valid-1b.hs: Likewise.
>
> --- gcc/c-family/c-opts.c.jj	2013-02-14 14:45:01.000000000 +0100
> +++ gcc/c-family/c-opts.c	2013-02-15 12:44:48.936535118 +0100
> @@ -945,6 +945,16 @@ c_common_post_options (const char **pfil
>   	 because the default address space slot then can't be used
>   	 for the output PCH file.  */
>         if (pch_file)
> +	{
> +	  c_common_no_more_pch ();
> +	  /* Only -g0 and -gdwarf* are supported with PCH, for other
> +	     debug formats we warn here and refuse to load any PCH files.  */
> +	  if (write_symbols != NO_DEBUG && write_symbols != DWARF2_DEBUG)
> +	    warning (OPT_Wdeprecated,
> +		     "the \"%s\" debug format cannot be used with "
> +		     "pre-compiled headers", debug_type_names[write_symbols]);
> +	}
> +      else if (write_symbols != NO_DEBUG && write_symbols != DWARF2_DEBUG)
>   	c_common_no_more_pch ();
>   
>         /* Yuk.  WTF is this?  I do know ObjC relies on it somewhere.  */
> --- gcc/testsuite/lib/dg-pch.exp.jj	2013-01-11 09:02:39.000000000 +0100
> +++ gcc/testsuite/lib/dg-pch.exp	2013-02-15 15:45:53.747855529 +0100
> @@ -16,8 +16,49 @@
>   
>   load_lib copy-file.exp
>   
> +proc pch-init { args } {
> +    global pch_unsupported_debug pch_unsupported
> +
> +    if [info exists pch_unsupported_debug] {
> +	error "pch-init: pch_unsupported_debug is not empty as expected"
> +    }
> +    if [info exists pch_unsupported] {
> +	error "pch-init: pch_unsupported is not empty as expected"
> +    }
> +
> +    set result [check_compile pchtest object "int i;" "-g -x c-header"]
> +    set pch_unsupported_debug \
> +	[regexp "debug format cannot be used with pre-compiled headers" \
> +		[lindex $result 0]]
> +
> +    set pch_unsupported 0
> +    if { $pch_unsupported_debug } {
> +	verbose -log "pch is unsupported with the debug info format"
> +
> +	set result [check_compile pchtest object "int i;" "-x c-header"]
> +	    set pch_unsupported \
> +		[regexp "debug format cannot be used with pre-compiled headers" \
> +			[lindex $result 0]]
> +    }
> +}
> +
> +proc pch-finish { args } {
> +    global pch_unsupported_debug pch_unsupported
> +    unset pch_unsupported_debug
> +    unset pch_unsupported
> +}
> +
> +proc check_effective_target_pch_supported_debug { } {
> +    global pch_unsupported_debug
> +    if { $pch_unsupported_debug } {
> +	return 0
> +    }
> +    return 1
> +}
> +
>   proc dg-flags-pch { subdir test otherflags options suffix } {
>       global runtests dg-do-what-default
> +    global pch_unsupported_debug pch_unsupported
>   
>       # If we're only testing specific files and this isn't one of them, skip it.
>       if ![runtest_file_p $runtests $test] {
> @@ -35,6 +76,13 @@ proc dg-flags-pch { subdir test otherfla
>       foreach flags $options {
>   	verbose "Testing $nshort, $otherflags $flags" 1
>   
> +	if { $pch_unsupported != 0 \
> +	     || ( $pch_unsupported_debug != 0 && [regexp " -g" " $flags"] ) } {
> +	    verbose -log "$nshort unsupported because debug format conflicts with PCH"
> +	    unsupported "$nshort $flags"
> +	    continue
> +	}
> +
>   	# For the header files, the default is to precompile.
>   	set dg-do-what-default precompile
>   	catch { file_on_host delete "$bname$suffix" }
> @@ -78,7 +126,8 @@ proc dg-flags-pch { subdir test otherfla
>    		    fail "$nshort $flags assembly comparison"
>   		}
>   	    }
> -	} else {
> +	} elseif { $pch_unsupported_debug == 0 \
> +		   || [llength [grep $test "{\[ \t\]\+dg-require-effective-target\[ \t\]\+pch_supported_debug\[ \t\]\+.*\[ \t\]\+}"]] > 0 } {
>   	    verbose -log "pch file '$bname$suffix.gch' missing"
>   	    fail "$nshort $flags"
>   	    if { !$have_errs } {
> --- gcc/testsuite/g++.dg/pch/pch.exp.jj	2013-01-11 09:02:44.000000000 +0100
> +++ gcc/testsuite/g++.dg/pch/pch.exp	2013-02-15 14:53:03.517106464 +0100
> @@ -23,6 +23,7 @@ load_lib dg-pch.exp
>   
>   # Initialize `dg'.
>   dg-init
> +pch-init
>   
>   set old_dg_do_what_default "${dg-do-what-default}"
>   
> @@ -36,4 +37,5 @@ foreach test [lsort [glob -nocomplain $s
>   set dg-do-what-default "$old_dg_do_what_default"
>   
>   # All done.
> +pch-finish
>   dg-finish
> --- gcc/testsuite/objc.dg/pch/pch.exp.jj	2013-01-11 09:02:44.000000000 +0100
> +++ gcc/testsuite/objc.dg/pch/pch.exp	2013-02-15 14:53:30.063951051 +0100
> @@ -24,8 +24,8 @@ load_lib torture-options.exp
>   
>   # Initialize `dg'.
>   dg-init
> -
>   torture-init
> +pch-init
>   
>   set-torture-options $DG_TORTURE_OPTIONS
>   
> @@ -59,5 +59,6 @@ if [istarget "*-*-darwin*" ] {
>   set dg-do-what-default "$old_dg_do_what_default"
>   
>   # All done.
> +pch-finish
>   torture-finish
>   dg-finish
> --- gcc/testsuite/gcc.dg/pch/pch.exp.jj	2013-01-11 09:02:42.000000000 +0100
> +++ gcc/testsuite/gcc.dg/pch/pch.exp	2013-02-15 14:11:27.053896809 +0100
> @@ -26,6 +26,7 @@ load_lib torture-options.exp
>   dg-init
>   torture-init
>   set-torture-options $DG_TORTURE_OPTIONS
> +pch-init
>   
>   set old_dg_do_what_default "${dg-do-what-default}"
>   
> @@ -59,5 +60,6 @@ file delete $testh
>   set dg-do-what-default "$old_dg_do_what_default"
>   
>   # All done.
> +pch-finish
>   torture-finish
>   dg-finish
> --- gcc/testsuite/gcc.dg/pch/valid-1.c.jj	2009-06-08 11:53:48.000000000 +0200
> +++ gcc/testsuite/gcc.dg/pch/valid-1.c	2013-02-15 15:19:44.124833259 +0100
> @@ -1,3 +1,4 @@
> +/* { dg-require-effective-target pch_supported_debug } */
>   /* { dg-options "-I. -Winvalid-pch -g" } */
>   
>   #include "valid-1.h"/* { dg-warning "created with -gnone, but used with -g" } */
> --- gcc/testsuite/gcc.dg/pch/valid-1.hs.jj	2008-09-05 12:54:26.000000000 +0200
> +++ gcc/testsuite/gcc.dg/pch/valid-1.hs	2013-02-15 15:19:50.686794340 +0100
> @@ -1,3 +1,4 @@
> +/* { dg-require-effective-target pch_supported_debug } */
>   /* { dg-options "-I. -Winvalid-pch -g0" } */
>   
>   extern int x;
> --- gcc/testsuite/gcc.dg/pch/valid-1b.c.jj	2008-09-05 12:54:26.000000000 +0200
> +++ gcc/testsuite/gcc.dg/pch/valid-1b.c	2013-02-15 15:19:55.935763631 +0100
> @@ -1,3 +1,4 @@
> +/* { dg-require-effective-target pch_supported_debug } */
>   /* { dg-options "-I. -Winvalid-pch -g0" } */
>   
>   #include "valid-1b.h"
> --- gcc/testsuite/gcc.dg/pch/valid-1b.hs.jj	2008-09-05 12:54:26.000000000 +0200
> +++ gcc/testsuite/gcc.dg/pch/valid-1b.hs	2013-02-15 15:20:02.214727794 +0100
> @@ -1,3 +1,4 @@
> +/* { dg-require-effective-target pch_supported_debug } */
>   /* { dg-options "-I. -Winvalid-pch -g" } */
>   
>   extern int x;
>
>
> 	Jakub
>
>
Dave

Re: [PATCH] Disable PCH for -g other than dwarf[234] (PR pch/54117, take 2)

[Jeff Law]

On 02/15/13 08:08, Jakub Jelinek wrote:
> On Thu, Feb 14, 2013 at 05:48:57AM -0700, Jeff Law wrote:
>> I think two tests should be sufficient.  First, compile a simple
>> program with -g and verify it generates dwarf2 debug records.
>> Second verify that there aren't any -g<foo> options, unless <foo> is
>> dwarf2.
>>
>> I'm actually on PTO today/tomorrow, so I won't be able to look
>> further at this until Monday.
>>
>> If someone wants to run with it, my recommendation would be Steven's
>> warning patch, moved to the location Jakub suggests so that users
>> know stabs+PCH is going away plus a hack to the testsuite suite
>> similar to what I outlined above plus something to either suppress
>> creation of the pch or suppress reading the PCH in the presence of
>> non-dwarf debug output.
>
> Here is what seems to work for me.
> Tested with
> make check -j4 -k RUNTESTFLAGS='--target_board=unix\{-m32,-m32/-gstabs,-m64,-m64/-gstabs\} pch.exp'
> on x86_64-linux, both with gcc just with this patch and also
> this patch + changed PREFERRED_DEBUGGING_TYPE to DBX_DEBUG.
> No FAILs at all, tests that wouldn't work because either -gstabs is forced
> in the flags from target board or tests that would be compiled with -g
> when stabs is the default are UNSUPPORTED.
>
> 2013-02-15  Jakub Jelinek  <jakub@redhat.com>
> 	    Steven Bosscher  <steven@gcc.gnu.org>
>
> 	PR pch/54117
> 	* c-opts.c (c_common_post_options): If debug info is enabled
> 	and non-dwarf*, refuse to load PCH files and when writing PCH
> 	file warn.
>
> 	* lib/dg-pch.exp (pch-init, pch-finish,
> 	check_effective_target_pch_supported_debug): New procs.
> 	(dg-flags-pch): If $pch_unsupported, make tests UNSUPPORTED.
> 	Likewise if $pch_unsupported_debug and $flags include -g.
> 	Skip FAILs about missing *.gch file if $pch_unsupported_debug
> 	and dg-require-effective-target pch_unsupported_debug.
> 	* g++.dg/pch/pch.exp: Call pch-init and pch-finish.
> 	* objc.dg/pch/pch.exp: Likewise.
> 	* gcc.dg/pch/pch.exp: Likewise.
> 	* gcc.dg/pch/valid-1.c: Add dg-require-effective-target
> 	pch_unsupported_debug.
> 	* gcc.dg/pch/valid-1.hs: Likewise.
> 	* gcc.dg/pch/valid-1b.c: Likewise.
> 	* gcc.dg/pch/valid-1b.hs: Likewise.
This is good.  Please install.
jeff

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Joel Brobecker]

> > >> 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
> > 
> > What is the status of merging Adacore's patches for DWARF support on AIX?

For cross-reference purposes, I sent the following update on
binutils:

        FYI: patches for powerpc-aix...
        http://www.sourceware.org/ml/binutils/2013-02/msg00233.html

So, not quite there yet, but getting a lot closer.

-- 
Joel

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[David Edelsohn]

On Thu, Feb 14, 2013 at 7:09 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>> >> 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
>>
>> What is the status of merging Adacore's patches for DWARF support on AIX?
>
> Sorry, David. I have been meaning to work on that ever since
> we talked about it...
>
> I spent some time today isolating the patches. I am currently
> testing the patches we wrote for support on AIX 5.3. I then see
> a few more patches to extend support to AIX 7.1 - section alignment
> constraints, and stuff related to TLS.
>
> Just for anyone who is curious, this is what I am testing.
> It is missing the pieces for the other tools such as objdump,
> for instance. But I think those can be submitted separately.

Joel,

Thanks!  That's great progress on the Binutils side.

What is the status of patches for GCC to generate DWARF for AIX XCOFF
and do the AIX assembler and linker recognize, consume and process the
directives produced by GCC correctly?

Thanks, David

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Joel Brobecker]

> Thanks!  That's great progress on the Binutils side.

You are very welcome.

> What is the status of patches for GCC to generate DWARF for AIX XCOFF
> and do the AIX assembler and linker recognize, consume and process the
> directives produced by GCC correctly?

I haven't looked at this part in details, but our recollection is that
it's a matter of configuring GCC with --with-gnu-as and --with-gnu-ld,
together with a small patch to make DWARF the default. AFAIK, the rest
should be working as expected.

-- 
Joel

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[David Edelsohn]

On Tue, Feb 19, 2013 at 11:11 AM, Joel Brobecker <brobecker@adacore.com> wrote:

> I haven't looked at this part in details, but our recollection is that
> it's a matter of configuring GCC with --with-gnu-as and --with-gnu-ld,
> together with a small patch to make DWARF the default. AFAIK, the rest
> should be working as expected.

A start is the patch that I sent you or Tristan a long time ago, but
simply enabling DWARF is not enough because XCOFF only supports some
of the sections and uses slightly different pseudo-ops.

* AIX 7.1 supports DWARF3 debugging, but XCOFF remains the default.  */
#define DWARF2_DEBUGGING_INFO 1
#define PREFERRED_DEBUGGING_TYPE XCOFF_DEBUG
#define DEBUG_INFO_SECTION  "\t.dwsect 0x10000,Ldebug_info..0"
#define DEBUG_ABBREV_SECTION "\t.dwsect 0x60000,Ldebug_abbrev..0"
#define DEBUG_ARANGES_SECTION "\t.dwsect 0x50000"
#define DEBUG_LINE_SECTION "\t.dwsect 0x20000,Ldebug_line..0"
#define DEBUG_PUBNAMES_SECTION "\t.dwsect 0x30000"
#define DEBUG_PUBTYPES_SECTION "\t.dwsect 0x40000"
#define DEBUG_STR_SECTION "\t.dwsect 0x70000"
#define DEBUG_RANGES_SECTION "\t.dwsect 0x80000,Ldebug_ranges..0"

Thanks, David

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Paolo Bonzini]

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?
>