Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Cc: Joel Brobecker <brobecker@adacore.com>
Subject: [RFA/Python] Fix procfs.c build failure on 32bit solaris (_FILE_OFFSET_BITS)
Date: Tue, 23 Nov 2010 01:14:00 -0000	[thread overview]
Message-ID: <1290474834-1945-1-git-send-email-brobecker@adacore.com> (raw)

This is a bit ugly...

A recent change introduced the include of "python-internal.h" from
inside breakpoint.h.  This in turn affected procfs.c:

| In file included from /usr/include/sys/procfs.h:29:0,
|                  from ../../src/gdb/core-regset.c:42:
| /usr/include/sys/old_procfs.h:39:2: error: #error "Cannot use procfs in the large file compilation environment"

What happens is that _FILE_OFFSET_BITS gets unconditionally re-defined
by pyconfig.h to a value that procfs.c does not support.  So far, we were
able to get by with the following #undef:

    /* On sparc-solaris, /usr/include/sys/feature_tests.h defines
       _FILE_OFFSET_BITS, which pyconfig.h also defines.  Same work
       around technique as above.  */
    #undef _FILE_OFFSET_BITS

...because procfs.c never included Python, even indirectly.  But this
is no longer sufficient, because the indirect dependency causes procfs.c
to get a value of _FILE_OFFSET_BITS that it does not support.

As I was looking at this, I looked at the configure script in Python 2.7,
and it appears that disabling large-file support is not possible.
Regardless of that, I think we want to be able to build GDB against
pre-built versions of Python if we can...

So the fix I applied was to make sure we restore the initial value
of _FILE_OFFSET_BITS after having included Python.h.

gdb/ChangeLog:

        * python/python-internal.h (_FILE_OFFSET_BITS): Restore initial value
        after having included "Python.h".

It fixes the problem on sparc-solaris. Tested on x86_64-linux.
OK to commit?

---
 gdb/python/python-internal.h |   18 ++++++++++++++++--
 1 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/gdb/python/python-internal.h b/gdb/python/python-internal.h
index 30d7533..026a05a 100644
--- a/gdb/python/python-internal.h
+++ b/gdb/python/python-internal.h
@@ -37,9 +37,16 @@
 #undef _XOPEN_SOURCE
 
 /* On sparc-solaris, /usr/include/sys/feature_tests.h defines
-   _FILE_OFFSET_BITS, which pyconfig.h also defines.  Same work
-   around technique as above.  */
+   _FILE_OFFSET_BITS, which pyconfig.h also defines.  We cannot apply
+   the same technique as above, because the actual value is important.
+   If we let Python define _FILE_OFFSET_BITS to a value that is not
+   compatible with procfs, we will get a compilation error while trying
+   to include sys/procfs.h.  To avoid that, we save the current value,
+   and restore it after Python.h has been included.  */
+#ifdef _FILE_OFFSET_BITS
+#define OLD_FILE_OFFSET_BITS _FILE_OFFSET_BITS
 #undef _FILE_OFFSET_BITS
+#endif
 
 #if HAVE_LIBPYTHON2_4
 #include "python2.4/Python.h"
@@ -62,6 +69,13 @@ typedef int Py_ssize_t;
 #error "Unable to find usable Python.h"
 #endif
 
+/* Restore the original _FILE_OFFSET_BITS value if applicable.  */
+#ifdef OLD_FILE_OFFSET_BITS
+#undef _FILE_OFFSET_BITS
+#define _FILE_OFFSET_BITS OLD_FILE_OFFSET_BITS
+#undef OLD_FILE_OFFSET_BITS
+#endif
+
 /* If Python.h does not define WITH_THREAD, then the various
    GIL-related functions will not be defined.  However,
    PyGILState_STATE will be.  */
-- 
1.7.1


             reply	other threads:[~2010-11-23  1:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-23  1:14 Joel Brobecker [this message]
2010-11-23  3:25 ` Jan Kratochvil
2010-11-23 12:42 ` Pedro Alves
2010-11-23 15:22   ` Tom Tromey
2010-11-23 16:29     ` Pedro Alves
2010-11-23 17:23       ` Phil Muldoon
2010-11-23 17:47         ` Pedro Alves
2010-11-24 17:20       ` Joel Brobecker
2010-11-25 13:12         ` Pedro Alves
2010-11-24 18:25       ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1290474834-1945-1-git-send-email-brobecker@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox