This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA/Python] Fix procfs.c build failure on 32bit solaris (_FILE_OFFSET_BITS)
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Cc: Joel Brobecker <brobecker at adacore dot com>
- Date: Tue, 23 Nov 2010 12:42:44 +0000
- Subject: Re: [RFA/Python] Fix procfs.c build failure on 32bit solaris (_FILE_OFFSET_BITS)
- References: <1290474834-1945-1-git-send-email-brobecker@adacore.com>
On Tuesday 23 November 2010 01:13:54, Joel Brobecker wrote:
> 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:
How hard would it be to get rid of the need to include
python-internal.h in any header? It's included by breakpoint.h
for PyObject,
/* With a Python scripting enabled GDB, store a reference to the
Python object that has been associated with this breakpoint.
This is always NULL for a GDB that is not script enabled. It
can sometimes be NULL for enabled GDBs as not all breakpoint
types are tracked by the Python scripting API. */
PyObject *py_bp_object;
Given that we only need to hold a pointer to this, thus the PyObject
need not be complete at this point, can we forward declare PyObject
instead somehow? If not, can we perhaps come up with a wrapper type
that itself can be forward declared? Or fallback to void* if nothing
else cleaner is possible? The advantage would be that python-internal.h
would then only be included in the specific modules that require it,
in other words, it would be moved to breakpoint.c.
WDYT?
--
Pedro Alves