DMD workforce contribution

[Gor Gyolchanyan]

> 1. Making shared libraries under Linux work would be a big improvement.

I think you meant "Making shared libraries, written in D, under Linux
work would be a big improvement.", because everything else works fine
(i tested it) using core.sys.posix.dlfn;
Since druntime needs some serious initialization, core.sys.windows.dll
was invented to hide away all this and, if I'm not mistaken, this is
precisely what it means to "support DLLs".
since .so files don't have any auto-called functions, like DllMain,
some additional shenanigans are required to get it to work as in
Windows. There will still be helper functions that would be put inside
some "main" function in .so functions, that should be called
explicitly when loaded (probably inside a standard library loader).
DllMain also has thread/process attach/detach routine callbacks, which
are, AFAIK, are not necessary to simulate in .so files (otherwise,
it'll go inside that pseudo-main function).
Regarding the above information, all I have to do to make "shared
libraries work under linux" is to make linux analogs for the dll
helper functions, define the pseudo-main function requirement in D
docs and make a specialization of LoadLibrary routine in druntime to
call that function.

I have a question regarding the general approach to shared libraries
in D: Should we really use obsolete C library formats and jump through
lots of hoops to work around the limitations?

AFAIK, currently "DLL support" is purely an optional druntime feature,
that allows one to quickly initialize druntime from DllMain by using
the functions for attaching/detaching a thread/process.
I understand, the GC, some handlers (like exception handler) as well
as any other things i don't know about should be properly initialized.
The problem is, that .so files in ELF format don't have anything similar.
In order to make the two consistent some common logic should be
developed on how does D treat

On Mon, Nov 7, 2011 at 1:51 PM, Walter Bright
<newshound2 at digitalmars.com> wrote:
> On 11/7/2011 1:19 AM, Gor Gyolchanyan wrote:
>>
>> I'm not quite familiar with DMD's internals, so the best answer would
>> be "whatever is more important to do".
>
> I take it you want to work on DMD itself, then!
>
> 1. Making shared libraries under Linux work would be a big improvement.
>
> 2. Another would be to investigate the Dwarf symbolic debug outfit and make
> dmd's output work well in gdb.
>
> 3. Run the dmd test suite under Linux with gcc's coverage analyzer turned
> on. Add test cases to cover dmd source code that is not tested.
>
> 4. There are many static analyzers on the market. Try compiling dmd with one
> or more of them, and propose fixes.
>
> 5. Go through the Bugzilla unresolved issues, pick what interests you, and
> propose patches to fix them.
>
> 6. Investigate popular benchmarks (such as the "shootout"). Compare the
> native code generated by dmd with that of C or C++, and identify inefficient
> code sequences.
>
> 7. Install NetBSD or OpenBSD, and port dmd to them.
>