Linking COFF and OMF

[Dmitry Olshansky]

On 22.02.2011 7:54, %u wrote:
>>> That's pretty good. Almost all of those things are standard C.
>>> LDIV and UDIV could easily be eliminated.
>>> __except_list is a null asm label (it is FS:[0]).
>>>
>>> So the main problematic ones are:
>>> _xi_a , __acrtused_con, the __fp functions, and _Ccmp
>> So how to tackle that?
> I'm really glad that this issue is being looked into. I've literally
> wasted days (if not a few weeks) getting another to work instead of
> SNN.lib, and I think that the ultimate culprit that prevented things
> from working was _xi_a.
> I couldn't figure out how to solve it; I'm not sure if it was the
> root cause, but I think it interfered with thread-static data,
> and/or the garbage collector.
>
> What does _xi_a even do? Is it anything more than just a marker
> inside the executable?

Inspired by your works, I wasted best part of two hours and managed the 
following:
replaced snn.lib with dummy one, for now I placed _acrt_used symbol 
there which happens to be weird 32bit integer, in fact.
rebuild C part of druntime with MS C compiler into druntime_c.lib 
(that's MS COFF lib all right)
rebuild the D part of druntime -> druntime.lib (that's OMF objects, they 
can't sit together)
phobos actually builds as usual though now it lacks parts that were in 
druntime_c.lib

then I linked simple program with MSVCRT lib and got
Error: No entry point

simple.d being:
import core.stdc.stdio;
void main(){
     printf("Holly crap!\n");
}

Some google-fu later I forcibly dragged mainCRTstartup symbol in, that's 
where is C runtime entry point for MSVCRT.
I went like this:
ulink  simple.obj -i_mainCRTStartup druntime_c.lib phobos.lib

Error: Unresolved external '__tlsend' referenced from 
'C:\ulink\phobos.lib|thread.d'
Error: Unresolved external '__tlsstart' referenced from 
'C:\ulink\phobos.lib|thread.d'
Error: Unresolved external '__LDIV@' referenced from 
'C:\ulink\phobos.lib|thread.d'
Error: Unresolved external '__xi_a' referenced from 
'C:\ulink\phobos.lib|memory.d'
Error: Unresolved external '___alloca' referenced from 
'C:\ulink\phobos.lib|dmain2.d'

that's where I stopped, technically it might still be attainable.
What I gather is that windows DMD itself emits direct references on 
__LDIV, __alloca and friends found in snn.
Maybe we can get out by writing simple thunk lib to replace snn.lib that 
maps these to MS runtime analogs if any.
 From druntime source I get an idea that __tlsstart, __tlsend are 
markers emitted by DMC dealing with them
and TLS in general would be trickier ;)

-- 
Dmitry Olshansky