Re: GDB 7.5.91 available for testing

Re: GDB 7.5.91 available for testing

[Eli Zaretskii]

> 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.)

Re: GDB 7.5.91 available for testing

[Joel Brobecker]

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

Thanks! Would you mind submitting each patch individually, so we can
track them? If there are any that you feel you can self-approve, please
also go ahead.

> 4. After I overcame all these issues, debugging GDB with itself
>    reveals more:
[...]
>    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.)

We already discussed this, and many different ideas were suggested,
but none that was satisfactory. You need to do what the testsuite does,
which is change a setting, I just don't remember which.

So far, none of the issues that you listed appear blocking. Am I right?

-- 
Joel

Re: GDB 7.5.91 available for testing

[Eli Zaretskii]

> Date: Wed, 13 Mar 2013 11:02:20 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org
> 
> > I built this natively on Windows with 32-bit MinGW tools, and bumped
> > into a few issues.
> 
> Thanks! Would you mind submitting each patch individually, so we can
> track them?

Done.

> If there are any that you feel you can self-approve, please also go
> ahead.

I need approval from DJ for the libiberty part.  As for the other one,
I'd prefer to hear approval, since it's semi-kludgey.

> >    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.)
> 
> We already discussed this, and many different ideas were suggested,
> but none that was satisfactory. You need to do what the testsuite does,
> which is change a setting, I just don't remember which.

Can anyone point me to the archives where this setting is described?
Thanks.

> So far, none of the issues that you listed appear blocking. Am I right?

Not blocking, although I'd prefer to have the warnings due to
pyerrors.h be fixed on the release branch.

Re: GDB 7.5.91 available for testing

[Jan Kratochvil]

On Wed, 13 Mar 2013 19:34:31 +0100, Eli Zaretskii wrote:
> Can anyone point me to the archives where this setting is described?

I was lazy to search for that discussion but if it is enough you can use:
	./gdb -data-directory ./data-directory/


Regards,
Jan

Re: sim/erc32/Makefile.in patch - was Re: GDB 7.5.91 available for testing

[Joel Brobecker]

[switching to gdb-patches]

On Thu, Mar 14, 2013 at 05:14:54PM -0400, Mike Frysinger wrote:
> On Wednesday 13 March 2013 14:17:59 Joel Brobecker wrote:
> > > The sim/erc32 will not build outside the source tree. It is
> > > missing a -I. to find config.h in the build tree.
> > > 
> > > mkdir b--gdb
> > > cd b-gdb
> > > ../gdb-7.5.91/configure --target=sparc-rtems4.11 \
> > >    --prefix=/home/joel/test-gdb/install/ \
> > >    --enable-sim --enable-sim-hardware  \
> > >     --enable-timebase --enable-sim-trace >c.log 2>&1 && \
> > >     make >b.log 2>&1 && \
> > >    make install >i.log 2>&1
> > > 
> > > Should be enough to reproduce it.
> > 
> > Thanks. Reproduced using configure --target=sparc-elf --enable-sim.
> > 
> > > 2013-03-13  Joel Sherrill <joel.sherrill@oarcorp.com>
> > > 
> > >         * Makefile.in: Include build directory in search path to find
> > >         config.h
> > 
> > After a quick review of the patch, it looks reasonable to me.
> > But Mike F is the Global Maintainer, so I'll defer to him.
> 
> OK

Thanks, Mike. Patch applied to both HEAD and the 7.6 branch.

-- 
Joel