www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Linking COFF and OMF

reply Trass3r <un known.com> writes:
 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
Feb 22 2011
parent reply %u <wfunction hotmail.com> writes:
 I'm really glad that this issue is being looked into. I've literally wasted
days (if not a few weeks) getting


_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. :)
Feb 22 2011
parent Trass3r <un known.com> writes:
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?
Feb 22 2011