type with constructor in namespace issue

[fxm]

Thanks badidea.

@Admins and others,

So it seems that the problem has nothing to do with the use of Poseidon, but would only be present when compiling for Linux 64-bit (no problem when compiling for Windows).

The problem when compiling for Linux 64-bit is:
- global variables are constructed after the module constructor execution (or module constructor is executed before global variables construction),
and symmetrically:
- global variables are destructed before the module destructor execution (or module destructor is executed after global variables destruction).

[badidea]

Lets draw some attention to this issue:

Top of my TODO list is the next FreeBASIC release.

Your list just got a bit longer :-)

[fxm]

Someone who uses Linux and observes this bug for a 64-bit target compilation can he fill in a bug report?
Otherwise I would do it, but just with the forum information!

[sancho3]

So it seems that the problem has nothing to do with the use of Poseidon, but would only be present when compiling for Linux 64-bit (no problem when compiling for Windows).

Yes its the 64 bit version of the compiler that doesn't work correctly.
My Geany and my terminal both were using the 32 bit version of the compiler and they both worked.
I just tried from the terminal using the 64bit fbc and it showed the problem.

I will post a bug report later, but I would like some help with the description.

[fxm]

I think that a bug report as following is pretty clear for a developer:

Bad timing on static object construction/destruction when compiling for Linux 64-bit

The fault when compiling for Linux 64-bit is the following:
- static (or global) objects are constructed after the module constructor execution instead of before,
and symmetrically:
- static (or global) objects are destructed before the module destructor execution instead of after.

The order is right when compiling for Linux 32-bit and Windows 32/64-bit.

Check there is not the same problem for static simple numeric variables initialization (value defined at declaration level).

+ one forum example (without namespace block)
+ a link to the forum topic

[St_W]

(@fxm: is the (de)initializer/constructor/destructor execution order documented or how do we know what's the "correct" behaviour? - I'm asking just out of interest)

[fxm]

More generally, this problem concerns the construction/destruction of static variables (a Dim Shared variable is also static by default).

For example, at the Storage Classes page of documentation, it is written:

Static variable, object and array lifetimes begin at program creation and end with program termination.

But no precision on the exact timing for initialization, except in the Glossary (S) at "static storage" paragraph:

static storage
Refers to storage in the .BSS or .DATA sections of an executable. Variables, objects and arrays with static storage are allocated and initialized at compile-time and destroyed (in the case of objects) and deallocated at program-termination. Explicitly initialized variables, objects and arrays are allocated in the .DATA section.

[fxm]

@sancho3 or @badidea or anyone which can compile and execute for Linux 64-bit, can you test this code?

Code: Select all

Type UDT1
  Dim As Integer I = 123
End Type

Type UDT2
  Dim As Integer I
  Declare Constructor ()
End Type
Constructor UDT2 ()
  This.I = 456
End Constructor

Dim Shared As UDT1 u1
Dim Shared As UDT2 u2
Dim Shared As Integer I = 789

Sub init () Constructor
  Print "from module constructor execution:"
  Print @u1.I, u1.I
  Print @u2.I, u2.I
  Print @I, i
  Print
  u1.I = 321
  u2.I = 654
  I = 987
End Sub

Print "after module constructor execution:"
Print @u1.I, u1.I
Print @u2.I, u2.I
Print @I, i
Print

Sleep

Normal output:

Code: Select all

from module constructor execution:
4239392        123
4239396        456
4223116        789

after module constructor execution:
4239392        321
4239396        654
4223116        987

[coderJeff]

slackware linux 64 bit (gcc version 5.3.0)

Code: Select all

from module constructor execution:
6312568        123
6312576        456
6312392        789

after module constructor execution:
6312568        321
6312576        654
6312392        987

The exact order is going to depend on the linker, the compiler, and the C-run time start-up code. I will have to research more to give a more technical & exact answer.

In general, data that requires a constructor procedure (UDT or module) can not be relied upon for execution order, and therefore global constructors that refers to another global also requiring a global constructor is not reliable.

The out-of-order problem becomes even more prominent with multiple modules (object files) also having module constructors and globally constructed variables.

[fxm]

This is why I would like to know how this behaves for a simple numerical variable (without constructor) with an initializer.
Let's see if sancho3 or badidea can give it a try.

If that (surprising for me) behavior is normal, it should be desirable for such global variables (with construction) have their accesses from a module constructor forbidden by the compiler.

[badidea]

@sancho3 or @badidea or anyone which can compile and execute for Linux 64-bit, can you test this code?

fbc32 -gen gas (1.05.0):

Code: Select all

from module constructor execution:
134533740      123
134533744      456
134533644      789

after module constructor execution:
134533740      321
134533744      654
134533644      987

fbc64 -gen gas (1.05.0):

Code: Select all

error 82: Selected -gen gas ASM backend for non-x86 CPU, x86-64

fbc32 -gen gcc (1.05.0):

Code: Select all

from module constructor execution:
134533740      0
134533744      0
134533644      789

after module constructor execution:
134533740      123
134533744      456
134533644      987

fbc64 -gen gcc (1.05.0):

Code: Select all

from module constructor execution:
6313104        0
6313112        0
6312984        789

after module constructor execution:
6313104        123
6313112        456
6312984        987

gcc --version:

Code: Select all

gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I guess, that last sentence explains it all ;-)

[fxm]

Thanks.
The problem is therefore only for static variables with constructor (explicit or implicit).

However, no problem for me with gcc both for Win32 and Win64.

[sancho3]

Bug report posted.
I used your description verbatim.

[coderJeff]

I left a longer answer on the bug report. Here's the short answer.

I installed ubuntu 14.04 and see the same behaviour. Yep, it all works as expected.

I think the confusing part for most people would be:
- module constructor
- object constructor
They sound related; they use a similar mechanism to function, but they are not related.

There are 2 important facts to know:
- module construction is independent and separate from object construction
- we see different behavior on different systems because of an gcc configuration option that is enabled on some systems and disabled on others.

module constructors expose a low level capability/feature of the linker and c run-time. For any other behaviour we would need to drop that feature and implement something else.

[fxm]

No confusion for me, but I logically thought that the construction of static/global objects was always done before the call of the module constructors, similar to the initialization of static/global simple variables.