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
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
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
dennis luehring Wrote:
i don't if the source of snn.lib is available - is it?
Don't think so, that's dmc land.
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
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
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)
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
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
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.
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
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.
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
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
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
%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
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
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
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
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
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?
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
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
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?
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
25 matches
Mail list logo
