Re: Linking COFF and OMF
what's the error?
I get an access violation at (or sometimes around) the statement
ModuleInfo* m = _moduleinfo_tlsdtors[i];
inside _moduleTlsDtor() in object_.d.
My entire code for the main file is below (although there's obviously more to
the process, like the .obj files,
a few other changes, etc.):
import core.stdc.wchar_ : wprintf;
import core.runtime : Runtime;
pragma(lib, msvcrt.lib);
pragma(startaddress, mainCRTStartup);
extern (C)
{
//Is this right? What does it even do?
static __gshared uint _acrtused_con = 0x9876;
int main(int argc, char** argv); //in dmain2.d
}
//Just to avoid bringing in Phobos here... unsafe though
void writefln(S...)(in wchar[] format, S args)
{ wprintf(format.ptr, args); wprintf(\n); }
extern (Windows) int mainCRTStartup()
{
Runtime.initialize();
scope(exit) Runtime.terminate(); // ERROR here
return main(0, null);
}
int main(string[] args)
{
writefln(%u, args.length);
return 0;
}
-
If I comment out the line with the error, it runs fine *inside* the Visual
Studio debugger, but crashes outside
(at a similar place)... can't figure it out, and I think you might need to
actually try it to see what I mean.
Any ideas?
Re: Linking COFF and OMF
So I continued my quest to remove the SNN.lib dependency (and instead depend on MSVCRT.dll), and ran into a Heisenbug that I think might relate to TLS. Basically, the bug shows up only if Visual Studio isn't attached to the program, and it only happens when the program is exiting. (!) Would anyone be willing to help me figure this out? I feel like I'm S close and yet so far! :( I didn't attach the files, but I could definitely write up a set of detailed instructions saying what I did. Is anyone interested? It seems to me like if we can only fix this one error, we should be done with porting druntime to SNN.lib, and then we can focus on porting higher-level things like std.stdio (which should be much more straightforward). Anyone interested?
Re: Linking COFF and OMF
Am 22.02.2011 05:54, schrieb %u: 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? i don't if the source of snn.lib is available - is it? but the new ida freeware version 5 (http://www.hex-rays.com/idapro/idadownfreeware.htm) is very nice for the lib-analysis (core32\cinit.asm)
Re: Linking COFF and OMF
dennis luehring Wrote: i don't if the source of snn.lib is available - is it? Don't think so, that's dmc land.
Re: Linking COFF and OMF
Am 21.02.2011 15:26, schrieb Don: Trass3r wrote: In 2.052 several of the most complicated dependencies on snn.lib (those relating to exception handling) were removed. I don't know how many more DMC-specific ones there are, but using another snn.lib might be possible now. Compiled a hello world with empty snn.lib: 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]). question out of curiosity - would it be a good idea (or technical solveable) to replace the snn.lib complete with D code?
Re: Linking COFF and OMF
Am 22.02.2011 05:54, schrieb %u: 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? some light in the darkness... http://www.nynaeve.net/?p=44
Re: Linking COFF and OMF
dennis luehring Wrote: question out of curiosity - would it be a good idea (or technical solveable) to replace the snn.lib complete with D code? Doesn't make sense since you'd have to introduce the D runtime into C runtime code (remember that dmc also uses that runtime for compiling C code) Furthermore I expect it wouldn't technically work cause the D runtime itself requires a C runtime.
Re: Linking COFF and OMF
Am 23.02.2011 12:56, schrieb Trass3r: dennis luehring Wrote: question out of curiosity - would it be a good idea (or technical solveable) to replace the snn.lib complete with D code? Doesn't make sense since you'd have to introduce the D runtime into C runtime code (remember that dmc also uses that runtime for compiling C code) Furthermore I expect it wouldn't technically work cause the D runtime itself requires a C runtime. introduce the D runtime into C runtime code why? (except you want to use the existing C runtime code) I expect it wouldn't technically work cause the D runtime itself requires a C runtime. ok maybe a bootstrap is needed - dmd/phobos links with snn.lib produced by dmc, and another compile/link run for dmd and phobos - with an D version of snn.lib i don't the big technical difficulty here - any special case? something that can't be done with D? do the WinApi needs some form of C-Runtime initalisation on Application-side? (i don't think so) - and the excecption-stuff is win-api based not c-runtime, or?
Re: Linking COFF and OMF
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
Re: Linking COFF and OMF
dennis luehring wrote: i don't if the source of snn.lib is available - is it? The complete source to DMC and it's libraries are available in the purchased development kit.
Re: Linking COFF and OMF
Dmitry Olshansky Wrote: 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 ;) Nice work so far :) Shouldn't something like alloca be available in VCRT as well?
Re: Linking COFF and OMF
On 2/23/11, dennis luehring dl.so...@gmx.net wrote: but the new ida freeware version 5 I did not know v5 went freeware. Fantastic, thanks.
Re: Linking COFF and OMF
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. What steps did you take? btw, I opened http://d.puremagic.com/issues/show_bug.cgi?id=5639 for this
Re: Linking COFF and OMF
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.
What steps did you take?
btw, I opened http://d.puremagic.com/issues/show_bug.cgi?id=5639 for this
Well, since I hate executables that reference numerous Kernel32 functions in
lieu of using MSVCRT's pre-prepared
environments (*especially* if they're ANSI functions), I got to work, figuring
out what was causing it. Some of the
functions turned out to be from Phobos, which I modified to work with MSVCRT
(e.g. I changed std.stdio to use
_fileno, etc.); many of them, though, were from SNN.lib. After lots of work
unpacking each and every object file from
snn, I found out that cinit.obj was a major cause of the bloat, so I created
another library file and added
everything necessary _except_ cinit.obj.
Well, I'm not sure if it should've been a surprise: cinit.obj was also
necessary. Why? Because of just a few fields,
especially _xi_a.
I tried disassembling things; I tried looking at Microsoft's CRT; I tried
looking everywhere on the web, but with no
luck... I couldn't figure out what the heck _xi_a was for. (I _think_) I looked
in the garbage collector, and found
out that apparently it was just a marker for part of the executable. I tried
making my own object file with the
symbol (with random bytes taken from the assembly, hoping to get it working),
but obviously it didn't work... I got
access violations. I fixed a few of them by taking out the 'version' condition
in dmain2.d, so that these lines would
also compile on Windows:
void _d_criticalInit()
{
version (Posix)
{
_STI_monitor_staticctor();
_STI_critical_init();
}
}
but this was only a partial fix for druntime, and it didn't fix everything. I
got random access violations in
different places (especially from stdio's module). I even posted a thread here
a few months ago about making our own
runtime instead of SNN.lib (I can't find the link at the moment), but didn't
get any real response... and I
eventually gave up; it didn't seem worth the effort.
My ultimate goals were:
1. To migrate to msvcrt.dll, and try to remove the ~100-200 KB bloat that the C
runtime from SNN.lib added to
everything.
2. To migrate _everything_ to NTDLL.dll (this was very ambitious, I admit),
which would be the ultimate low-level
portion of the Windows NT user-mode API. Why? Because given that D is a systems
programming language, it should be
able to be used to make NT-native programs, that solely depend on NTDLL.dll.
(An example of such a program is
CheckDisk, which runs without the Win32 subsystem.) Currently, D is a systems
programming language in name only;
it's not actually possible to do any low-level programming in it unless we can
remove the SNN.lib dependency
entirely.
So that's the adventure I've gone through... I've also tried doing various
other things in the meanwhile (e.g. I
wrote my own boot loader + nanokernel using D, but ran into trouble when I
tried to get the garbage collector to
work, because of so many issues with SNN.lib and also with thread-local
storage.) These took many weeks of
[ultimately fruitless] effort, so now I'm happy that someone else also
mentioned the topic; hopefully it'll be
possible to remove the SNN.lib dependency.
That's my story. :)
Re: Linking COFF and OMF
Sounds like a lot of fun ;) I'm also sick of dmd's policy to mess everything up on Windows by completely depending on dmc and its friends while Linux users have a proper linker, libc and object format. I mean wouldn't it be the easiest way to use COFF + MinGW's ld and libc since it's very similar to what is used on Linux?
Re: Linking COFF and OMF
%u wrote: What does _xi_a even do? Is it anything more than just a marker inside the executable? have you seen this page: http://wiki.osdev.org/C_PlusPlus#Visual_C.2B.2B ? I think dmc is pretty much in line with it. You can also find these sections in the map files generated when compiling a D file with dmd.
Re: Linking COFF and OMF
What does _xi_a even do? Is it anything more than just a marker inside the executable? have you seen this page: http://wiki.osdev.org/C_PlusPlus#Visual_C.2B.2B ? I think dmc is pretty much in line with it. You can also find these sections in the map files generated when compiling a D file with dmd. :O no, I hadn't! That's great information; thanks!
Re: Linking COFF and OMF
In 2.052 several of the most complicated dependencies on snn.lib (those relating to exception handling) were removed. I don't know how many more DMC-specific ones there are, but using another snn.lib might be possible now. Compiled a hello world with empty snn.lib: OPTLINK (R) for Win32 Release 8.00.8 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html helloworld.obj(helloworld) Error 42: Symbol Undefined __acrtused_con C:\dmd\windows\bin\..\lib\phobos.lib(dmain2) Error 42: Symbol Undefined ___alloca C:\dmd\windows\bin\..\lib\phobos.lib(dmain2) Error 42: Symbol Undefined __except_list helloworld.obj(helloworld) Error 42: Symbol Undefined _fprintf C:\dmd\windows\bin\..\lib\phobos.lib(dmain2) Error 42: Symbol Undefined _wcslen C:\dmd\windows\bin\..\lib\phobos.lib(deh) Error 42: Symbol Undefined __tls_array C:\dmd\windows\bin\..\lib\phobos.lib(deh) Error 42: Symbol Undefined __tls_index C:\dmd\windows\bin\..\lib\phobos.lib(gc) Error 42: Symbol Undefined _memcpy C:\dmd\windows\bin\..\lib\phobos.lib(gc) Error 42: Symbol Undefined _malloc C:\dmd\windows\bin\..\lib\phobos.lib(memory) Error 42: Symbol Undefined __xi_a C:\dmd\windows\bin\..\lib\phobos.lib(memory) Error 42: Symbol Undefined __end C:\dmd\windows\bin\..\lib\phobos.lib(gcx) Error 42: Symbol Undefined _calloc C:\dmd\windows\bin\..\lib\phobos.lib(gcx) Error 42: Symbol Undefined _free C:\dmd\windows\bin\..\lib\phobos.lib(gcx) Error 42: Symbol Undefined _memset C:\dmd\windows\bin\..\lib\phobos.lib(object_) Error 42: Symbol Undefined _strlen C:\dmd\windows\bin\..\lib\phobos.lib(thread) Error 42: Symbol Undefined __beginthreadex C:\dmd\windows\bin\..\lib\phobos.lib(thread) Error 42: Symbol Undefined __tlsend C:\dmd\windows\bin\..\lib\phobos.lib(thread) Error 42: Symbol Undefined __tlsstart C:\dmd\windows\bin\..\lib\phobos.lib(object_) Error 42: Symbol Undefined _memcmp C:\dmd\windows\bin\..\lib\phobos.lib(gcx) Error 42: Symbol Undefined _memmove C:\dmd\windows\bin\..\lib\phobos.lib(gcx) Error 42: Symbol Undefined _realloc C:\dmd\windows\bin\..\lib\phobos.lib(regexp) Error 42: Symbol Undefined _printf C:\dmd\windows\bin\..\lib\phobos.lib(regexp) Error 42: Symbol Undefined _memchr C:\dmd\windows\bin\..\lib\phobos.lib(datetime) Error 42: Symbol Undefined _localtime C:\dmd\windows\bin\..\lib\phobos.lib(datetime) Error 42: Symbol Undefined _tzset C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined __iob C:\dmd\windows\bin\..\lib\phobos.lib(monitor) Error 42: Symbol Undefined __assert C:\dmd\windows\bin\..\lib\phobos.lib(lifetime) Error 42: Symbol Undefined __LDIV@ C:\dmd\windows\bin\..\lib\phobos.lib(outbuffer) Error 42: Symbol Undefined __vsnprintf C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _fclose C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _tmpfile C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _ftell C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _fseek C:\dmd\windows\bin\..\lib\phobos.lib(exception) Error 42: Symbol Undefined _strerror C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _setmode C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined ___fhnd_info C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _fread C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _fopen C:\dmd\windows\bin\..\lib\phobos.lib(conv) Error 42: Symbol Undefined __ULDIV@ C:\dmd\windows\bin\..\lib\phobos.lib(format) Error 42: Symbol Undefined ___pfloatfmt C:\dmd\windows\bin\..\lib\phobos.lib(errno) Error 42: Symbol Undefined _errno C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined ___fp_unlock C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined __fgetc_nlock C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined __fgetwc_nlock C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined ___fp_lock C:\dmd\windows\bin\..\lib\phobos.lib(ti_cfloat) Error 42: Symbol Undefined __Ccmp
Re: Linking COFF and OMF
Trass3r wrote: In 2.052 several of the most complicated dependencies on snn.lib (those relating to exception handling) were removed. I don't know how many more DMC-specific ones there are, but using another snn.lib might be possible now. Compiled a hello world with empty snn.lib: 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 OPTLINK (R) for Win32 Release 8.00.8 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html helloworld.obj(helloworld) Error 42: Symbol Undefined __acrtused_con C:\dmd\windows\bin\..\lib\phobos.lib(dmain2) Error 42: Symbol Undefined ___alloca C:\dmd\windows\bin\..\lib\phobos.lib(dmain2) Error 42: Symbol Undefined __except_list helloworld.obj(helloworld) Error 42: Symbol Undefined _fprintf C:\dmd\windows\bin\..\lib\phobos.lib(dmain2) Error 42: Symbol Undefined _wcslen C:\dmd\windows\bin\..\lib\phobos.lib(deh) Error 42: Symbol Undefined __tls_array C:\dmd\windows\bin\..\lib\phobos.lib(deh) Error 42: Symbol Undefined __tls_index C:\dmd\windows\bin\..\lib\phobos.lib(gc) Error 42: Symbol Undefined _memcpy C:\dmd\windows\bin\..\lib\phobos.lib(gc) Error 42: Symbol Undefined _malloc C:\dmd\windows\bin\..\lib\phobos.lib(memory) Error 42: Symbol Undefined __xi_a C:\dmd\windows\bin\..\lib\phobos.lib(memory) Error 42: Symbol Undefined __end C:\dmd\windows\bin\..\lib\phobos.lib(gcx) Error 42: Symbol Undefined _calloc C:\dmd\windows\bin\..\lib\phobos.lib(gcx) Error 42: Symbol Undefined _free C:\dmd\windows\bin\..\lib\phobos.lib(gcx) Error 42: Symbol Undefined _memset C:\dmd\windows\bin\..\lib\phobos.lib(object_) Error 42: Symbol Undefined _strlen C:\dmd\windows\bin\..\lib\phobos.lib(thread) Error 42: Symbol Undefined __beginthreadex C:\dmd\windows\bin\..\lib\phobos.lib(thread) Error 42: Symbol Undefined __tlsend C:\dmd\windows\bin\..\lib\phobos.lib(thread) Error 42: Symbol Undefined __tlsstart C:\dmd\windows\bin\..\lib\phobos.lib(object_) Error 42: Symbol Undefined _memcmp C:\dmd\windows\bin\..\lib\phobos.lib(gcx) Error 42: Symbol Undefined _memmove C:\dmd\windows\bin\..\lib\phobos.lib(gcx) Error 42: Symbol Undefined _realloc C:\dmd\windows\bin\..\lib\phobos.lib(regexp) Error 42: Symbol Undefined _printf C:\dmd\windows\bin\..\lib\phobos.lib(regexp) Error 42: Symbol Undefined _memchr C:\dmd\windows\bin\..\lib\phobos.lib(datetime) Error 42: Symbol Undefined _localtime C:\dmd\windows\bin\..\lib\phobos.lib(datetime) Error 42: Symbol Undefined _tzset C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined __iob C:\dmd\windows\bin\..\lib\phobos.lib(monitor) Error 42: Symbol Undefined __assert C:\dmd\windows\bin\..\lib\phobos.lib(lifetime) Error 42: Symbol Undefined __LDIV@ C:\dmd\windows\bin\..\lib\phobos.lib(outbuffer) Error 42: Symbol Undefined __vsnprintf C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _fclose C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _tmpfile C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _ftell C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _fseek C:\dmd\windows\bin\..\lib\phobos.lib(exception) Error 42: Symbol Undefined _strerror C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _setmode C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined ___fhnd_info C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _fread C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined _fopen C:\dmd\windows\bin\..\lib\phobos.lib(conv) Error 42: Symbol Undefined __ULDIV@ C:\dmd\windows\bin\..\lib\phobos.lib(format) Error 42: Symbol Undefined ___pfloatfmt C:\dmd\windows\bin\..\lib\phobos.lib(errno) Error 42: Symbol Undefined _errno C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined ___fp_unlock C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined __fgetc_nlock C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined __fgetwc_nlock C:\dmd\windows\bin\..\lib\phobos.lib(stdio) Error 42: Symbol Undefined ___fp_lock C:\dmd\windows\bin\..\lib\phobos.lib(ti_cfloat) Error 42: Symbol Undefined __Ccmp
Re: Linking COFF and OMF
Don 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 Yep, they need to be taken care of anyway to support 64Bit on Windoze, some of them are even written in asm. Member ..\core32\cinit.asm Offset 0x700 __argc _errno __argv __xi_a Member llmath.asm Offset 0x7E540 __LCMP@ __LDIV@ __LMUL@ __ULDIV@ Member ..\win32\constart.c Offset 0x5B280 BSS __acrtused_con
Re: Linking COFF and OMF
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?
Re: Linking COFF and OMF
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?
Linking COFF and OMF
I just took a stab at linking together different object formats with
UniLink.
Well, it just works(tm). So I may suggest to anyone having to link with
precompiled COFF static libs on windows to try it out.
For starters I just replaced most of my kernel32.lib, shell32.lib etc
with Microsoft SDK latest COFF import lib variants and
then built and linked winsamp.d from the DMD examples dir. Of course,
that broke optlink linkage.
Then I tried it with static libs, so I produced simplistic static lib
with MinGW gcc:
#include stdio.h
int AddInt(int i1, int i2)
{
return i1 + i2;
}
void PrintInt(int a)
{
printf(%d\n,a);
}
and linked with this module:
import std.stdio;
extern(C) int AddInt(int a,int b);
extern(C) int PrintInt(int a);
void main(){
assert(AddInt(3,5) == 8);
PrintInt(42);
writeln(Works?);
}
All passed as expected. (It took renaming lib from *.a to *.lib but
that's it!)
I guess it linked printf with DMC's printf in snn.lib though,
so there might be some problems with foreign RTLs when one goes too far.
P.S. I know I sound like a freaking promoter ;)
--
Dmitry Olshansky
Re: Linking COFF and OMF
I guess it linked printf with DMC's printf in snn.lib though, so there might be some problems with foreign RTLs when one goes too far. Can we replace snn with the other RTL?
Re: Linking COFF and OMF
Trass3r wrote: I guess it linked printf with DMC's printf in snn.lib though, so there might be some problems with foreign RTLs when one goes too far. Can we replace snn with the other RTL? In 2.052 several of the most complicated dependencies on snn.lib (those relating to exception handling) were removed. I don't know how many more DMC-specific ones there are, but using another snn.lib might be possible now.
