This is the mail archive of the gdb-cvs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

src/gdb ChangeLog configure configure.ac irix5 ...


CVSROOT:	/cvs/src
Module name:	src
Changes by:	brobecke@sourceware.org	2010-12-14 07:17:15

Modified files:
	gdb            : ChangeLog configure configure.ac irix5-nat.c 

Log message:
	build failure on IRIX when building with Python support.
	
	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.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.12379&r2=1.12380
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/configure.diff?cvsroot=src&r1=1.321&r2=1.322
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/configure.ac.diff?cvsroot=src&r1=1.135&r2=1.136
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/irix5-nat.c.diff?cvsroot=src&r1=1.57&r2=1.58


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]