py-breakpoint.c fails to compile with MinGW GCC

py-breakpoint.c fails to compile with MinGW GCC

[Eli Zaretskii]

The error message is:

  ./python/py-breakpoint.c:1019: error: initializer element is not constant
  ./python/py-breakpoint.c:1019: error: (near initialization for `breakpoint_objec t_type.tp_new')

This is with MinGW GCC 3.4.2 (yes, old, but it worked fine for me
until now).

I have Python 2.7.1 installed on that machine.

Removing the last element of the initializer, i.e. this line:

  PyType_GenericNew		  /* tp_new */

allows py-breakpoint.c to compile.

Is this a bug in GCC, in GDB, in Python, or in my setup?

TIA

Re: py-breakpoint.c fails to compile with MinGW GCC

[Phil Muldoon]

Eli Zaretskii <eliz@gnu.org> writes:

> The error message is:
>
>   ./python/py-breakpoint.c:1019: error: initializer element is not constant
>   ./python/py-breakpoint.c:1019: error: (near initialization for `breakpoint_objec t_type.tp_new')
>
> This is with MinGW GCC 3.4.2 (yes, old, but it worked fine for me
> until now).
>
> I have Python 2.7.1 installed on that machine.
>
> Removing the last element of the initializer, i.e. this line:
>
>   PyType_GenericNew		  /* tp_new */
>
> allows py-breakpoint.c to compile.
>
> Is this a bug in GCC, in GDB, in Python, or in my setup?
>
> TIA

There was a patch for this:

http://sourceware.org/ml/gdb-patches/2010-09/msg00214.html

Specifically from that email:

"- I have to modify some gdb python files because the files 'python-function.c', python-cmd.c (...) define some 'static PyTypeObject'.
  The field 'tp_new' of these static variables is statically initialized with the python 'PyType_GenericNew' function. 
  In Windows port of Python, this function is declared as a dllimport one and cannot be copied at compilation time in a static variable.
  For these files, I modified the source code
      - to initialize the 'tp_new' fields to '0' in the static variables and
      - to affect the proper 'PyType_GenericNew' value in the 'gdbpy_initialize_commands', 'gdbpy_initialize_frames' (...). "

It does not seem to have been checked in, even though it was reviewed.
I'm also unsure why some folks can compile ok (Dan in that email
mentions he has been), and some can't.

Cheers

Phil

Re: py-breakpoint.c fails to compile with MinGW GCC

[Tom Tromey]

Phil> It does not seem to have been checked in, even though it was reviewed.

It needed changes.

Phil> I'm also unsure why some folks can compile ok (Dan in that email
Phil> mentions he has been), and some can't.

I am unsure as well.

Tom

Re: py-breakpoint.c fails to compile with MinGW GCC

[Joel Brobecker]

> Phil> I'm also unsure why some folks can compile ok (Dan in that email
> Phil> mentions he has been), and some can't.

It does compile for me too. Could be a compiler age issue?
Just wondering out loud - if we were to use a C++ compiler, would
it allow us to use non-static initializers like in this case?
I'm under the impression that C++ provides elaboration, so
non-static initialization should be do-able...

-- 
Joel

Re: py-breakpoint.c fails to compile with MinGW GCC

[Phil Muldoon]

Joel Brobecker <brobecker@adacore.com> writes:

>> Phil> I'm also unsure why some folks can compile ok (Dan in that email
>> Phil> mentions he has been), and some can't.
>
> It does compile for me too. Could be a compiler age issue?
> Just wondering out loud - if we were to use a C++ compiler, would
> it allow us to use non-static initializers like in this case?
> I'm under the impression that C++ provides elaboration, so
> non-static initialization should be do-able...

Maybe older versions of Python did not tag with dllimport, or these
particular pieces.  I don't have access to a windows box locally, so I'm
just guessing/speculating.

Cheers

Phil

Re: py-breakpoint.c fails to compile with MinGW GCC

[Tom Tromey]

Joel> It does compile for me too. Could be a compiler age issue?

I asked Kai and that is what he thinks.

The Python docs don't say much:

    We’d like to just assign this to the tp_new slot, but we can’t, for
    portability sake, On some platforms or compilers, we can’t statically
    initialize a structure member with a function defined in another C
    module, so, instead, we’ll assign the tp_new slot in the module
    initialization function just before calling PyType_Ready():

See http://docs.python.org/extending/newtypes.html

Joel> Just wondering out loud - if we were to use a C++ compiler, would
Joel> it allow us to use non-static initializers like in this case?
Joel> I'm under the impression that C++ provides elaboration, so
Joel> non-static initialization should be do-able...

That would work; and while I want to do this, I think it is simpler to
just fix the initializations.  Or, just require people to use a newer
GCC; 3.4 is 5 years old at this point.

Tom

Re: py-breakpoint.c fails to compile with MinGW GCC

[Kai Tietz]

2011/7/28 Tom Tromey <tromey@redhat.com>:
> Joel> It does compile for me too. Could be a compiler age issue?
>
> I asked Kai and that is what he thinks.
>
> The Python docs don't say much:
>
>    We’d like to just assign this to the tp_new slot, but we can’t, for
>    portability sake, On some platforms or compilers, we can’t statically
>    initialize a structure member with a function defined in another C
>    module, so, instead, we’ll assign the tp_new slot in the module
>    initialization function just before calling PyType_Ready():
>
> See http://docs.python.org/extending/newtypes.html
>
> Joel> Just wondering out loud - if we were to use a C++ compiler, would
> Joel> it allow us to use non-static initializers like in this case?
> Joel> I'm under the impression that C++ provides elaboration, so
> Joel> non-static initialization should be do-able...
>
> That would work; and while I want to do this, I think it is simpler to
> just fix the initializations.  Or, just require people to use a newer
> GCC; 3.4 is 5 years old at this point.
>
> Tom

I looked a bit more in detail on this issue and indeed it is a
compiler age issue.  Newer compilers with pseudo-relocation support
are able to handle DLL-imported symbols in assignments for
global/static variables.
This is for older gcc versions (and indeed 3.4 is pretty old one) not possible.

Regards,
Kai

Re: py-breakpoint.c fails to compile with MinGW GCC

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb@sourceware.org
> Date: Thu, 28 Jul 2011 09:01:31 -0600
> 
> Phil> It does not seem to have been checked in, even though it was reviewed.
> 
> It needed changes.

Any hints as to what changes are needed?  Is it just to move the call
before PyType_Ready ?  TIA

Anyway, I think it's a pity we released 7.3 with this problem
unsolved.

Re: py-breakpoint.c fails to compile with MinGW GCC

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Cc: pmuldoon@redhat.com, Eli Zaretskii <eliz@gnu.org>, gdb@sourceware.org
> Date: Thu, 28 Jul 2011 09:43:59 -0600
> 
> Or, just require people to use a newer GCC; 3.4 is 5 years old at
> this point.

Just to clarify: I never upgraded my GCC because the existing 4.x
series (a) produce code that is less debug-friendly under any non-zero
optimization level, (b) some versions are buggy (e.g., 4.5), and
(c) is slower.  Paying compilation time penalty without any visible
gains seemed unwise, especially since my main development machine runs
on 6-year-old hardware.

I will probably upgrade when 4.7 is released, because I understand it
will be more debug-friendly.

Re: py-breakpoint.c fails to compile with MinGW GCC

[Joel Brobecker]

> Anyway, I think it's a pity we released 7.3 with this problem
> unsolved.

It's the first time I hear about this problem. It's inevitable
that we miss little problems like these, but there have been
numerous calls over a large period of time for known problems
that needed fixing.

I think that the way to avoid this in the future is for people
to take the pre-release, and try it out as soon as it comes out.
Otherwise, there is no point in me spending the time to make
a pre-release at all.

-- 
Joel

Re: py-breakpoint.c fails to compile with MinGW GCC

[Tom Tromey]

Eli> I will probably upgrade when 4.7 is released, because I understand it
Eli> will be more debug-friendly.

Is there something specific in 4.7 you are waiting for?  4.6 is probably
good enough -- it has the biggest improvement (VTA -- first in 4.5) plus
a few more -- but I don't know of anything so major that would advise
skipping 4.6.

In practice I build gdb with -O0 when I want to debug.  Occasionally I
just rebuild a single .o this way.  VTA is good, but when debugging I
care about 100% visibility into the source and nearly zero about
performance.

Tom

Re: py-breakpoint.c fails to compile with MinGW GCC

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> Any hints as to what changes are needed?  Is it just to move the call
Eli> before PyType_Ready ?  TIA

Move each affected initializer out of the structure and into the
function definition before the PyType_Ready call.  See the link I
provided to the Python docs, it has a worked example.

Eli> Anyway, I think it's a pity we released 7.3 with this problem
Eli> unsolved.

Not many people care about GCC 3.4 any more.

Tom

Re: py-breakpoint.c fails to compile with MinGW GCC

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Cc: brobecker@adacore.com, pmuldoon@redhat.com, gdb@sourceware.org
> Date: Thu, 28 Jul 2011 10:46:13 -0600
> 
> Eli> I will probably upgrade when 4.7 is released, because I understand it
> Eli> will be more debug-friendly.
> 
> Is there something specific in 4.7 you are waiting for?  4.6 is probably
> good enough -- it has the biggest improvement (VTA -- first in 4.5) plus
> a few more -- but I don't know of anything so major that would advise
> skipping 4.6.

I somehow thought VTA will be only in 4.7, thanks for getting me
straight.  However, the MinGW site doesn't have 4.6 available yet, so
in practice I still need to wait.

> In practice I build gdb with -O0 when I want to debug.

I'm forced to do the same, but I hate that.  End users will use -O2
(because that's how the Makefile's are set by default), so I'm testing
code that is different from what will run out there.

> Occasionally I just rebuild a single .o this way.

That only helps if that object file has all the story for you.  It
doesn't help with backtraces that cross object file boundaries, for
example.

> but when debugging I care about 100% visibility into the source and
> nearly zero about performance.

Of course.  But some problems are only present in optimized code, as
we all well know.

Re: py-breakpoint.c fails to compile with MinGW GCC

[Chris Sutcliffe]

On 28 July 2011 13:06, Eli Zaretskii wrote:
> I somehow thought VTA will be only in 4.7, thanks for getting me
> straight.  However, the MinGW site doesn't have 4.6 available yet, so
> in practice I still need to wait.

FWIW, it's coming down the pipe, just some back-end work needs to be
done in terms of dependent libraries, etc.

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

Re: py-breakpoint.c fails to compile with MinGW GCC

[Eli Zaretskii]

> Date: Thu, 28 Jul 2011 23:04:28 -0400
> From: Chris Sutcliffe <ir0nh34d@gmail.com>
> 
> On 28 July 2011 13:06, Eli Zaretskii wrote:
> > I somehow thought VTA will be only in 4.7, thanks for getting me
> > straight.  However, the MinGW site doesn't have 4.6 available yet, so
> > in practice I still need to wait.
> 
> FWIW, it's coming down the pipe, just some back-end work needs to be
> done in terms of dependent libraries, etc.

Thanks for the info, it's good to know it will be available soon.