How to kill GNAT DLL initialization?

[Dmitry A. Kazakov]

As it seems GNAT DLL may not have initialization code invoked in
DllMain. This inevitable deadlocks RTS. Removing user library-level
tasks does not help. The RTS itself contains library-level tasks. E.g.
when asynchronous select is used.

Now the question is how to kill calls to initialization code from DllMain.

for Library_Auto_Init use "false";

Is not enough. Are there other attributes I missed?

(Maybe there is a way to remove DllMain from the external symbols list
during linking?)

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[ahlan.m...@gmail.com]

Dear Dmitry,

We produce DLLs written using GNAT that are used by other languages - typically C++
We don't explicitly run any initialisation code, the main procedure is always empty.
(although this is probably a left over from our ObjectAda days)
If something has to be initialised then we put this into a procedure, export it and request that our C++ user calls this before calling any other routine.

Here is a typical Gpr file for one of our Dlls.

-------
project Monitor is

package Naming is
for Casing use "mixedcase";
end Naming;

for Library_Name use "Monitor";
for Shared_Library_Prefix use "";

for Source_Dirs use ("W:\Source\Ada\Interfaces\Monitor",
"W:\Source\Ada\Interfaces",
"W:\Source\Ada\Shared",
"W:\Source\Ada\Open\Shared",
"W:\Source\Ada\Open\Shared\Windows");

for Library_Interface use ("Monitor_Interface");

for Object_Dir use "objects";

for Library_Options use ("-LW:\Product\Windows", "resources.o");
for Library_Dir use "W:\Product\Windows";
for Library_Ali_Dir use "D:\Binary\Ada\Interfaces\Monitor";
for Library_Kind use "dynamic";
for Library_Standalone use "encapsulated";

package Pretty_Printer is
for Default_Switches ("ada") use ("-i2", "-M120", "-aL", "-A1", "-A4");
end Pretty_Printer;

package Builder is
for Default_Switches ("ada") use ("-s", "-g");
end Builder;

package Compiler is
for Default_Switches ("ada") use
("-O1", "-gnatQ", "-gnata", "-gnato", "-g", "-gnat12",
"-gnatwcehijkmopruvz.c.n.p.t.w.x", "-gnatykmpM120");
end Compiler;

package Binder is
for Default_Switches ("ada") use ("-E");
end Binder;

end Monitor;

-------

and the main package.

-------
with Monitor_Interface; --> UD: Drag in Code

procedure Monitor is
begin
null;
end Monitor;
-------

Monitor_Interface ads exports all the procedures that the DLL provides and the Adb implements them.

Hoping this helps,
MfG
Ahlan

[Dmitry A. Kazakov]

On 10/08/2016 22:18, ahlan.m...@gmail.com wrote:
> On Wednesday, 10 August 2016 14:52:33 UTC+2, Dmitry A. Kazakov wrote:
>> As it seems GNAT DLL may not have initialization code invoked in
>> DllMain. This inevitable deadlocks RTS. Removing user library-level
>> tasks does not help. The RTS itself contains library-level tasks. E.g.
>> when asynchronous select is used.
>>
>> Now the question is how to kill calls to initialization code from DllMain.
>>
>> for Library_Auto_Init use "false";
>>
>> Is not enough. Are there other attributes I missed?
>>
>> (Maybe there is a way to remove DllMain from the external symbols list
>> during linking?)
>>

> We produce DLLs written using GNAT that are used by other languages - typically C++
> We don't explicitly run any initialisation code, the main procedure is always empty.
> (although this is probably a left over from our ObjectAda days)
> If something has to be initialised then we put this into a
> procedure, export it and request that our C++ user calls this before calling any
> other routine.

Yes, that is my plan too. GNAT generates files b__dllname.ads/adb
containing an initialization procedure dllnameinit. This must be called
to initialize the RTS. The problem is that it is called automatically
upon DLL load on the context where it freezes. I must find a way to kill
that call.

My gpr project is no different, except that Library_Interface is a
package with some procedures.

> -------
>
> and the main package.
>
> -------
> with Monitor_Interface; --> UD: Drag in Code
>
> procedure Monitor is
> begin
> null;
> end Monitor;
> -------
>
> Monitor_Interface ads exports all the procedures that the DLL
> provides and the Adb implements them.

I found that my version of GNAT puts the DLL initialization program into
the .ctor section. That causes it called regardless anything.

[ahlan.m...@gmail.com]

Dear Dmitry,
I can't help but feel that you are going about this the wrong way.
I don't think you should be trying to prevent initialisation.
If you succeed then your DLL probably won't work because things need to be initialised.
We do all our PC programming in Ada.
Unfortunately not everyone is so enlightened and so we have to produce DLLs for other departments to use.
Consequently we have over the years produced a good many Windows DLLs that are used by a variety of languages, including Microsoft C++ and even Ada.
(We do in fact have a problem when our DLLs are called by an Ada program that uses Gtk later than 3.8.2 running on Windows XP - however I suspect that this isn't the problem you are experiencing)
Although our main is empty this is just because our main package has no code - the other packages have normal initialisation code and of course are elaborated.
The three things we need to be careful with are:
1) The interface has to use the C calling convention - including callbacks.
2) We don't attempt to propagate exceptions. Our interfaces are all functions that return a return code. Exceptions in the DLL are caught in the interface procedures and converted into an error code that is passed back to the caller.
3) Tasks must not be created either in package bodies nor in their elaboration. My guess is this is where your problem really lies. You can't have static tasks, only dynamic tasks and these must not be created in the package body - i.e. as part of the package elaboration or between the package begin and end.

The task restriction is normally where we trip over. So I suggest that you check very carefully where your tasks are being created. They can only be created as a result of being called by the DLL user not automatically by the DLL.

This is why most of our DLLs provide a function called Initialise that we require the DLL user to call before using any other of the provided functions. We also usually have a Finalise procedure that the DLL user must call so that we can terminate all our tasks - otherwise the main program won't exit.

Really, creating DLLs using a recent version (>=GPL;2014) of GNAT isn't a problem.
It is a bit more complicated if you are using a older version of GNAT because GNAT did not automatically make the transitive closure and on really old versions of GNAT you had to manually cause the DLL packages to be elaborated using AdaInit - but that is another story...

[Dmitry A. Kazakov]

On 12/08/2016 09:56, ahlan.m...@gmail.com wrote:

> I can't help but feel that you are going about this the wrong way.

I found the reason, in the project file the "-a" switch was specified
explicitly for default Binder switches. That overrode the effect of

for Library_Auto_Init use "false";

> I don't think you should be trying to prevent initialisation.

That is the only way because my DLL uses tasking.

> If you succeed then your DLL probably won't work because things need to be initialised.

My DLL interface calls to initialization from all exported operation.

> We do all our PC programming in Ada.
> Unfortunately not everyone is so enlightened and so we have to produce DLLs for other departments to use.

There are other reasons to use encapsulated libraries. GNU linker
performance becomes catastrophic with the number of libraries we have.
But I would prefer an ability to have accumulating library projects that
will produce single static or dynamic library out of multiple libraries.
Encapsulated GNAT run-time is not an issue to me.

> The task restriction is normally where we trip over. So I suggest
> that you check very carefully where your tasks are being created. They can
> only be created as a result of being called by the DLL user not
> automatically by the DLL.

That is a bug on GNAT's side, IMO. The problem is not only tasks but
also asynchronous select. If you have any, RTS will create an internal
task during initialization and so freeze. Possibly there are other cases
when Lock_RTS is called. It is Lock_RTS that causes freezing.

[ahlan.m...@gmail.com]

Dear Dmitry,
I am glad that you managed to solve your problem.
Although I wonder what you are doing that requires you to disable the library auto init.
We don't for any of our DLLs almost all of which create and use tasks although not from the dll_Main nor during elaboration.

Bes wishes,
Ahlan

[Dmitry A. Kazakov]

On 2016-08-13 10:59, ahlan.m...@gmail.com wrote:
> Although I wonder what you are doing that requires you to disable the
> library auto init.

Whatever that calls Lock_RTS during initialization.

> We don't for any of our DLLs almost all of which create and use
> tasks although not from the dll_Main nor during elaboration.

As I said, it is required but not sufficient. It would be nice if
AdaCore provided a full list. If you want to know, you must scan all RTS
files for calls to Lock_RTS and see if any of the subprograms doing this
is called from b__libnameinit.

Even better, they should make Windows gnatbind fail when the
initialization procedure it generates will freeze. It is clearly a bug
to me.