Re: GDB 7.5.91 available for testing

[Eli Zaretskii <eliz at gnu dot org>]

> Date: Tue, 12 Mar 2013 16:17:27 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> 
> I have just finished creating the gdb-7.5.91 pre-release.
> It is available for download at the following location:
> 
>     ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-7.5.91.tar.bz2
> 
> A gzip'ed version is also available: gdb-7.5.91.tar.gz.
> 
> Please give it a test if you can and report any problems you might find.

I built this natively on Windows with 32-bit MinGW tools, and bumped
into a few issues.

1. Compilation warning in libiberty:

     gcc -c -DHAVE_CONFIG_H -O2 -gdwarf-2 -g3 -D__USE_MINGW_ACCESS  -I. -I./../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  ./setenv.c -o setenv.o
     ./setenv.c:66:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]

   This happens because MinGW's stdlib.h has this:

     #ifdef __MSVCRT__
       extern _CRTIMP char *** __cdecl __MINGW_NOTHROW __p__environ(void);
       extern _CRTIMP wchar_t *** __cdecl __MINGW_NOTHROW  __p__wenviron(void);
     # define _environ (*__p__environ())
     # define _wenviron (*__p__wenviron())
     #else /* ! __MSVCRT__ */
     #endif /* ! __MSVCRT__ */

     #define environ _environ

   and setenv.c does this:

     #ifndef HAVE_ENVIRON_DECL
     extern char **environ;
     #endif

   Solution: Add a guard:

--- libiberty/setenv.c~	2011-02-03 09:23:59.000000000 +0200
+++ libiberty/setenv.c	2013-03-13 13:22:49.085187200 +0200
@@ -63,8 +63,10 @@
 
 #define __environ	environ
 #ifndef HAVE_ENVIRON_DECL
+#ifndef environ
 extern char **environ;
 #endif
+#endif

   If people here think this makes sense, I will submit this patch for
   libiberty.

2. Any source file which includes pyerrors.h triggers warnings like
   this:

     In file included from d:/usr/Python26/include/Python.h:120:0,
		      from python/python-internal.h:50,
		      from varobj.c:41:
     d:/usr/Python26/include/pyerrors.h:316:0: warning: "snprintf" redefined [enabled by default]
     In file included from ./common/gdb_locale.h:27:0,
		      from defs.h:66,
		      from varobj.c:18:
     d:\usr\bin\../lib/gcc/mingw32/4.7.2/../../../../include/libintl.h:353:0: note: this is the location of the previous definition

   This happens because Python's pyerrors.h has this:

     #if defined(MS_WIN32) && !defined(HAVE_SNPRINTF)
     # define HAVE_SNPRINTF
     # define snprintf _snprintf
     # define vsnprintf _vsnprintf
     #endif

   But libintl.h has this:

     #undef snprintf
     #define snprintf libintl_snprintf
     extern int snprintf (char *, size_t, const char *, ...);
     #undef vsnprintf
     #define vsnprintf libintl_vsnprintf
     extern int vsnprintf (char *, size_t, const char *, va_list);

   Solution: Define HAVE_SNPRINTF in defs.h:

--- gdb/defs.h~0	2013-02-04 14:57:44.000000000 +0200
+++ gdb/defs.h	2013-03-13 13:39:22.245759200 +0200
@@ -58,6 +58,11 @@
 
 #include <fcntl.h>
 
+/* A kludge to avoid redefinition of snprintf on Windows by pyerrors.h.  */
+#if defined(_WIN32) && defined(HAVE_DECL_SNPRINTF)
+#define HAVE_SNPRINTF 1
+#endif
+
 /* First include ansidecl.h so we can use the various macro definitions
    here and in all subsequent file inclusions.  */
 

   Is it OK to install this workaround?

(The above 2 problems are not new in the code, I guess I never saw
them before because I used an old version of GCC.  The newer one I use
now is more pedantic, and also I think the configure script detected
the new version of GCC and added a few warning switches to the bunch.)

3. If you have ncurses installed, the configure script will detect
   that and link GDB and Readline against libncurses.  But the
   resulting binary of GDB is broken: every keystroke produces "Quit"
   and exits the debugger.  I needed to move ncurses out of the way to
   get a working binary.  I will investigate when I have time
   (probably a conflict between Windows-specific portions of Readline
   and ncurses' getch or some such.  For now, I just mention this here
   for the record.

4. After I overcame all these issues, debugging GDB with itself
   reveals more:

     d:\usr\eli\utils\gdb-7.5.91\gdb>.\gdb ./gdb.exe
     Python Exception <type 'exceptions.NameError'> name 'os' is not defined:

     warning: Could not load the Python gdb module from `d:\usr\share\gdb/python'.

     warning: Limited Python support is available from the _gdb module.
     GNU gdb (GDB) 7.5.91
     Copyright (C) 2013 Free Software Foundation, Inc.
     License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
     This is free software: you are free to change and redistribute it.
     There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
     and "show warranty" for details.
     This GDB was configured as "i686-pc-mingw32".
     For bug reporting instructions, please see:
     <http://www.gnu.org/software/gdb/bugs/>...
     Reading symbols from d:\usr\eli\utils\gdb-7.5.91\gdb\gdb.exe...done.
     Setting up the environment for debugging gdb.
     During symbol reading, cannot get low and high bounds for subprogram DIE at 14910504.
     During symbol reading, No DW_FORM_block* DW_AT_GNU_call_site_value for DW_TAG_GNU_call_site child DIE 0xe38b76 [in module d:\usr\eli\utils\gdb-7.5.91\gdb\gdb.exe].
     During symbol reading, Only single DW_OP_reg or DW_OP_fbreg is supported for DW_FORM_block* DW_AT_location is supported for DW_TAG_GNU_call_site child DIE 0xe38db6 [in module d:\usr\eli\utils\gdb-7.5.91\gdb\gdb.exe].
     During symbol reading, Child DIE 0xe3acd7 and its abstract origin 0xe3fe60 have different tags.
     During symbol reading, Child DIE 0xe3acd7 and its abstract origin 0xe3fe60 have different parents.
     During symbol reading, DW_AT_GNU_call_site_target target DIE has invalid low pc, for referencing DIE 0xe3b481 [in module d:\usr\eli\utils\gdb-7.5.91\gdb\gdb.exe].
     During symbol reading, Multiple children of DIE 0xe3b813 refer to DIE 0xe386a5 as their abstract origin.
     During symbol reading, debug info gives command-line macro definition with non-zero line 1: __STDC__ 1.
     Breakpoint 1 at 0x5ab8bc: file utils.c, line 950.
     Breakpoint 2 at 0x440bd4: file ./cli/cli-cmds.c, line 221.
     Traceback (most recent call last):
       File "d:\usr\eli\utils\gdb-7.5.91\gdb\gdb-gdb.py", line 18, in <module>
	 import gdb
       File "d:\usr\share\gdb/python\gdb\__init__.py", line 23, in <module>
	 'gdb.function': os.path.join(gdb.PYTHONDIR, 'gdb', 'function'),
     NameError: name 'os' is not defined
     (top-gdb)

   Looks like it reads Python init files from the installed (previous)
   GDB version, and barfs.  How to tell it to use its own Python
   files?  It would be a nuisance not to be able to run GDB without
   installing it first.

   Also, are the DWARF-related warnings serious or expected?  (I'm
   using GCC 4.7.2, the latest one available from MinGW.)