043b651001
This is a nasty interaction between Python and GDB. Basically,
Python causes some macros to be unilaterally defined in order
to turns some features on:
/* Define to activate features from IEEE Stds 1003.1-2001 */
#define _POSIX_C_SOURCE 200112L
/* Define to the level of X/Open that your system supports */
#define _XOPEN_SOURCE 600
But the problem is that they turn off defines provided by some
system headers on which we depend. Namely:
* sys/siginfo.h:
#if _SGIAPI
#define siginfo __siginfo
#endif
* sys/ucontext.h:
#if _SGIAPI && !defined(__SGI_NOUCONTEXT_COMPAT)
[...]
#define fp_r __fp_r
[...]
#define fp_csr __fp_csr
[...]
#endif
The important macro here is _SGIAPI, defined as follow in standards.h:
#define _SGIAPI ((defined(_SGI_SOURCE) && \
_NO_POSIX && _NO_XOPEN4 && _NO_XOPEN5) || \
(_ANSIMODE && _NO_POSIX && _NO_XOPEN4 && _NO_XOPEN5))
If one builds GDB without Python, then _SGIAPI is true, and all is fine.
But building with Python causes both _POSIX_C_SOURCE and _XOPEN_SOURCE
to trip all the _NO_[...] tests (_NO_POSIX, _NO_XOPEN4, _NO_XOPEN5).
And so we get build failures because we try to use undefined types, or
non-existent component names inside the regset structure.
The latter problem is observed only within irix5-nat.c, which means
that it is specific to IRIX. So it's easy to write the code in a way
that it does not require the macros (just use the real component names,
rather than relying on the macros to do the translation).
The former, on the other hand, is a little trickier, because the problem
occurs inside a generic unit (procfs.c). The solution I chose was to
adjust the configure script to add -Dsiginfo=__siginfo to the CPPFLAGS
if building with python using GCC on IRIX.
We hadn't seen this sort of issue up to now because the affect units
have not been dependent on the python includes up to now. Recent changes
have made them indirectly dependent on Python, thus triggering the issues.
gdb/ChangeLog:
* irix5-nat.c: Replace fp_r, fp_regs and fp_scr by __fp_r, __fp_regs
and __fp_scr respectively throughout.
* configure.ac: Compile with -Dsiginfo=__siginfo if building with
Python using GCC on IRIX.
* configure: Regenerate.
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.