* Re: GDB 7.5.91 available for testing
[not found] <20130312231727.GF31629@adacore.com>
@ 2013-03-13 17:50 ` Eli Zaretskii
2013-03-13 18:02 ` Joel Brobecker
[not found] ` <5140904A.2040206@oarcorp.com>
1 sibling, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2013-03-13 17:50 UTC (permalink / raw)
To: Joel Brobecker; +Cc: gdb-patches
> 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.)
^ permalink raw reply [flat|nested] 5+ messages in thread