GDB Python extension on AIX

GDB Python extension on AIX

[David Edelsohn]

When Python is installed correctly on AIX and the GDB configuration
process finds Python, some of the source files that implement the GDB
Python extension fail to compile on AIX with the following error:

In file included from
/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/6.1.0/include/c++/math.h:36:0,
                 from build-gnulib/import/math.h:27,
                 from /opt/freeware/include/python2.7/pyport.h:325,
                 from /opt/freeware/include/python2.7/Python.h:58,
                 from /home/dje/src/binutils-gdb/gdb/python/python-internal.h:9
,
                 from /home/dje/src/binutils-gdb/gdb/python/python.c:94:
/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/6.1.0/include/c++/cmath:640:11:
error: '::isnan' has not been declared
   using ::isnan;
           ^~~~~
Makefile:2593: recipe for target 'python.o' failed

This is due to a Python extension header redefining feature test
macros in the compiler namespace that interfere with AIX math.h and
libstdc++ math.h behavior

gdb/python/python-internal.h includes the following fragment:

/* Python 2.4 doesn't include stdint.h soon enough to get {u,}intptr_t
   needed by pyport.h.  */
/* /usr/include/features.h on linux systems will define _POSIX_C_SOURCE
   if it sees _GNU_SOURCE (which config.h will define).
   pyconfig.h defines _POSIX_C_SOURCE to a different value than
   /usr/include/features.h does causing compilation to fail.
   To work around this, undef _POSIX_C_SOURCE before we include Python.h.

   Same problem with _XOPEN_SOURCE.  */
#undef _POSIX_C_SOURCE
#undef _XOPEN_SOURCE

Redefining and undefining feature test macros, such as _POSIX_C_SOURCE
and _XOPEN_SOURCE are not very wise things to do, especially in the
middle of a sequence of includes that already may have included other
system header files with conditionals that were affected by the macros
in their original state.

If I comment out this unfortunate fragment, GDB is able to compile on
AIX with the Python extension.

Is this fragment necessary for other targets?  Would the GDB community
at least be open to a proposal to bracket this fragment with

#ifndef _AIX
...
#endif

?

What is the preferred way to address this?

Thanks, David

Re: GDB Python extension on AIX

[David Edelsohn]

On Thu, Aug 11, 2016 at 3:29 AM, Andreas Schwab <schwab@suse.de> wrote:
> On Aug 11 2016, David Edelsohn <dje.gcc@gmail.com> wrote:
>
>> What is the preferred way to address this?
>
> The preferred way is to arrange to include <pyconfig.h> before any
> system headers.  And file a bug with python that their use of feature
> test macros makes this necessary.

Python already is aware of the problem

https://bugs.python.org/issue17120


GDB chose to manipulate the feature test macros further to avoid build
warnings instead of re-arranging the order of headers:


commit aac63f0f2626a3fce5ee936f07ecb48ab7b12ca8
Author: Joel Brobecker <brobecker@gnat.com>
Date:   Wed Jun 30 23:12:04 2010 +0000

    Fix build failure with Python installed in non-system location.

    The debugger fails to build when configure with --python-python=<path>
    where <path> is a non-system location.  The reason is a warning made
    fatal due to the definition of _XOPEN_SOURCE inside pyconfig.h.  This
    is exactly the same problem as with _POSIX_C_SOURCE, handled in
    python-internal.h as follow:

    | /* /usr/include/features.h on linux systems will define _POSIX_C_SOURCE
    |    if it sees _GNU_SOURCE (which config.h will define).
    |    pyconfig.h defines _POSIX_C_SOURCE to a different value than
    |    /usr/include/features.h does causing compilation to fail.
    |    To work around this, undef _POSIX_C_SOURCE before we include Python.h.
 */
    | #undef _POSIX_C_SOURCE

    This patch fixes this problem the same way.

    2010-06-30  Joel Brobecker  <brobecker@adacore.com>

            * python/python-internal.h (_XOPEN_SOURCE): Undefine before
            including Python.h.


I think the ball is in GDB's court.

If GDB is going to intervene in these macros for some systems and
configuratino, I request a method to disable this for AIX.

Thanks, David

Re: GDB Python extension on AIX

[Joel Brobecker]

> I think the ball is in GDB's court.
> 
> If GDB is going to intervene in these macros for some systems and
> configuratino, I request a method to disable this for AIX.

Seems like a reasonable request to me, at least as a stop-gap measure.
If there is a way to do things more correctly, perhaps we could look at
that as a second step.

Note that it is strange that I don't see the error you are seeing.
But perhaps it has to do with the fact that we use a version of
Python which we built and installed at a non-standard location?

-- 
Joel

Re: GDB Python extension on AIX

[David Edelsohn]

On Thu, Aug 18, 2016 at 3:21 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> I think the ball is in GDB's court.
>>
>> If GDB is going to intervene in these macros for some systems and
>> configuratino, I request a method to disable this for AIX.
>
> Seems like a reasonable request to me, at least as a stop-gap measure.
> If there is a way to do things more correctly, perhaps we could look at
> that as a second step.
>
> Note that it is strange that I don't see the error you are seeing.
> But perhaps it has to do with the fact that we use a version of
> Python which we built and installed at a non-standard location?

Hi, Joel

Thanks for looking into this and for considering some sort of work-around.

I'm not sure what a "standard" location is on AIX.  I was using the
Bull Freeware installation of Python in /opt/freeware.

Was the Python installation found and recognized on your AIX system?
Until some of my more recent changes, GDB configure did not consider
the installation correct to try to build the GDB feature.

AIX, unfortunately, is very delicate and picky about header inclusion
order and feature macros.

Thanks, David

Re: GDB Python extension on AIX

[Joel Brobecker]

> I'm not sure what a "standard" location is on AIX.  I was using the
> Bull Freeware installation of Python in /opt/freeware.
> 
> Was the Python installation found and recognized on your AIX system?
> Until some of my more recent changes, GDB configure did not consider
> the installation correct to try to build the GDB feature.

In our case, we configure GDB with --with-python=/path/to/python,
so it doesn't need to be a location that the configury would find
by itself. In your case, I think what's happening is that you have
/opt/freeware/bin in your PATH, and that allows the GDB configury
to find that python and therefore use it.

-- 
Joel

Re: GDB Python extension on AIX

[David Edelsohn]

On Fri, Aug 19, 2016 at 1:49 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> I'm not sure what a "standard" location is on AIX.  I was using the
>> Bull Freeware installation of Python in /opt/freeware.
>>
>> Was the Python installation found and recognized on your AIX system?
>> Until some of my more recent changes, GDB configure did not consider
>> the installation correct to try to build the GDB feature.
>
> In our case, we configure GDB with --with-python=/path/to/python,
> so it doesn't need to be a location that the configury would find
> by itself. In your case, I think what's happening is that you have
> /opt/freeware/bin in your PATH, and that allows the GDB configury
> to find that python and therefore use it.

This probably relates to the original conflict between implicit and
explicit paths that you were trying to fix

Would the appended patch be an acceptable approach?

Thanks, David

gdb/
* python/python-internal.h: Don't redefine _POSIX_C_SOURCE and
_XOPEN_SOURCE on AIX.

diff --git a/gdb/python/python-internal.h b/gdb/python/python-internal.h
index 8545c7b..6378ccc 100644
--- a/gdb/python/python-internal.h
+++ b/gdb/python/python-internal.h
@@ -72,8 +72,12 @@
    To work around this, undef _POSIX_C_SOURCE before we include Python.h.

    Same problem with _XOPEN_SOURCE.  */
+
+/* A kludge to avoid overriding on AIX.  */
+#ifndef _AIX
 #undef _POSIX_C_SOURCE
 #undef _XOPEN_SOURCE
+#endif

 /* On sparc-solaris, /usr/include/sys/feature_tests.h defines
    _FILE_OFFSET_BITS, which pyconfig.h also defines.  Same work

Re: GDB Python extension on AIX

[Joel Brobecker]

> Would the appended patch be an acceptable approach?

Sorry for the late reply (holidays and traveling). That would
seem reasonable to me, but patches in the python/ subdir have
traditionally been Tom and Doug's territory.

My suggestion is to modify your comment about AIX to include
the issue you've been describing in this email chain, to make it
easier to remember why the workaround should not be applied on
AIX, and then resubmit on gdb-patches, with Doug Evans in Cc:.

> gdb/
> * python/python-internal.h: Don't redefine _POSIX_C_SOURCE and
> _XOPEN_SOURCE on AIX.
> 
> diff --git a/gdb/python/python-internal.h b/gdb/python/python-internal.h
> index 8545c7b..6378ccc 100644
> --- a/gdb/python/python-internal.h
> +++ b/gdb/python/python-internal.h
> @@ -72,8 +72,12 @@
>     To work around this, undef _POSIX_C_SOURCE before we include Python.h.
> 
>     Same problem with _XOPEN_SOURCE.  */
> +
> +/* A kludge to avoid overriding on AIX.  */
> +#ifndef _AIX
>  #undef _POSIX_C_SOURCE
>  #undef _XOPEN_SOURCE
> +#endif
> 
>  /* On sparc-solaris, /usr/include/sys/feature_tests.h defines
>     _FILE_OFFSET_BITS, which pyconfig.h also defines.  Same work

-- 
Joel