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
