On 10/8/2014 11:19 AM, Rainer Schuetze wrote:
> There is no perfect plan how an application can change the default options that
> are used without arguments, though. Doing this in main() is too late for some
> parameters (e.g. "precise"), because the GC will have to be setup to execute
> "static this" and other library initialization before reaching main.

I meant look for the argument in the C main() which is part of druntime and is the first to get control. You're right that the D main() is too late.

On 08.10.2014 22:10, Walter Bright wrote:
> On 10/8/2014 11:19 AM, Rainer Schuetze wrote:
>> There is no perfect plan how an application can change the default
>> options that
>> are used without arguments, though. Doing this in main() is too late
>> for some
>> parameters (e.g. "precise"), because the GC will have to be setup to
>> execute
>> "static this" and other library initialization before reaching main.
>
> I meant look for the argument in the C main() which is part of druntime
> and is the first to get control. You're right that the D main() is too
> late.

C main is no longer under user control, because it is auto-generated with D main. I never liked that change, we've just discovered another reason.

On 08/10/14 22:47, Rainer Schuetze wrote:

> C main is no longer under user control, because it is auto-generated
> with D main. I never liked that change, we've just discovered another
> reason.

All platforms have API's to access the command line arguments passed to "main". On OS X that would be "_NSGetArgv" and "_NSGetArgc".

-- 
/Jacob Carlborg

On 09.10.2014 08:29, Jacob Carlborg wrote:
> On 08/10/14 22:47, Rainer Schuetze wrote:
>
>> C main is no longer under user control, because it is auto-generated
>> with D main. I never liked that change, we've just discovered another
>> reason.
>
> All platforms have API's to access the command line arguments passed to
> "main". On OS X that would be "_NSGetArgv" and "_NSGetArgc".
>

Yes, but the problem is not to access command line arguments, but to run code before the GC initialization i.e. before _d_run_main is executed.

If we can assume a C++ backend, using static initialization of a C++ global could work:

   static bool initGC = configureGC();

because the C++ runtime runs configureGC before calling C main. I'd rather like to see a solution using D, though.

On 10/8/2014 11:43 PM, Rainer Schuetze wrote:
> Yes, but the problem is not to access command line arguments, but to run code
> before the GC initialization i.e. before _d_run_main is executed.
>
> If we can assume a C++ backend, using static initialization of a C++ global
> could work:
>
>     static bool initGC = configureGC();
>
> because the C++ runtime runs configureGC before calling C main. I'd rather like
> to see a solution using D, though.

Define a global variable in druntime in its own module:

    __gshared int druntime_flags = 0;

Then, in your app, override it:

    __gshared int druntime_flags = values...;

On 09/10/14 08:43, Rainer Schuetze wrote:

> Yes, but the problem is not to access command line arguments, but to run
> code before the GC initialization i.e. before _d_run_main is executed.
>
> If we can assume a C++ backend, using static initialization of a C++
> global could work:
>
>     static bool initGC = configureGC();
>
> because the C++ runtime runs configureGC before calling C main. I'd
> rather like to see a solution using D, though.

It's enough with a C function with __attribute__((constructor)). This will run before C main.

-- 
/Jacob Carlborg

On Wednesday, 8 October 2014 at 17:39:46 UTC, Walter Bright wrote:
> On 10/8/2014 12:43 AM, Leandro Lucarella wrote:
>> I think this is an unjustified fear, there are already many environment
>> variables that can affect your program. That's why they are called...
>> environment variables :)
>
> Being on the front lines of tech support for 30 years, it is not an unjustified fear nor a hypothetical problem.
>
> What you could do is propose a "secret" switch to all dmd generated programs that the druntime switch checks before main() gets control, such as:
>
>     app --druntimeSet=usexxx ...the regular app args ...

Back when Druntime was called Ares, it was possible to choose the GC at link time.  Do we really need to defer the decision to run time?  If so, switching GCs after the app has started should work in most cases, though I'm not sure offhand if memory allocated by the prior GC will be scanned through for references within the new GC.

On Thursday, 9 October 2014 at 14:20:07 UTC, Sean Kelly wrote:
> Back when Druntime was called Ares, it was possible to choose the GC at link time.  Do we really need to defer the decision to run time?  If so, switching GCs after the app has started should work in most cases, though I'm not sure offhand if memory allocated by the prior GC will be scanned through for references within the new GC.

This also forces GC implementations to aware of each other. Not normally an issue but GC traditionally includes many extern(C) functions with common names which will need to be always implemented so that all GC implementations are supported.

At the same time I don't see what real benefit such runtime options brings to the table. This is why in my PR garbage collector is currently chosen during compilation time.

On 09.10.2014 10:18, Walter Bright wrote:
> On 10/8/2014 11:43 PM, Rainer Schuetze wrote:
>> Yes, but the problem is not to access command line arguments, but to
>> run code
>> before the GC initialization i.e. before _d_run_main is executed.
>>
>> If we can assume a C++ backend, using static initialization of a C++
>> global
>> could work:
>>
>>     static bool initGC = configureGC();
>>
>> because the C++ runtime runs configureGC before calling C main. I'd
>> rather like
>> to see a solution using D, though.
>
> Define a global variable in druntime in its own module:
>
>      __gshared int druntime_flags = 0;
>
> Then, in your app, override it:
>
>      __gshared int druntime_flags = values...;

That's similar to my approach to replace gc.config by a different module with the same module name when compiling the executable:

  dmd main.d my_gc_config.d

where my_gc_config.d contains "module gc.config;" and thus replaces the module in the library.

Martin is very much against this, one reason is that it does not work with druntime in a shared library.

On 09.10.2014 15:31, Jacob Carlborg wrote:
> On 09/10/14 08:43, Rainer Schuetze wrote:
>
>> Yes, but the problem is not to access command line arguments, but to run
>> code before the GC initialization i.e. before _d_run_main is executed.
>>
>> If we can assume a C++ backend, using static initialization of a C++
>> global could work:
>>
>>     static bool initGC = configureGC();
>>
>> because the C++ runtime runs configureGC before calling C main. I'd
>> rather like to see a solution using D, though.
>
> It's enough with a C function with __attribute__((constructor)). This
> will run before C main.
>

This is a gcc extension, which isn't supported under Windows by dmd. Can you add this attribute in GDC/LDC as part of a D file aswell?

I recently made some experiments with pragma(data_seg,"SEGMENT_NAME") or pragma(code_seg,"SEGMENT_NAME") that could also be used to move something into the initializer section of the runtime. For COFF it kind of works, but unfortunately there is no way to tell OMF to put a COMDAT (needed for templates) into a specific segment.