> > P.S. Incidentally, while I am on the subject, I find myself able to trace
> > through the VM startup code in Visual Studio with no problem at all, until I
> > get to the factor_vm::c_to_factor, which wraps a c-to-factor sub-primitive
> > inside of a callback stub and then invokes that function. On both a Windows
> > 7 platform and a Windows Server 2008 platform, my Visual Studio blows up
> > when the callback address loaded into EDX is called. Anybody ever
> > encountered this and any idea how to get around it?
>
> Factor code doesn't follow the C calling convention so it's unlikely
> that a debugger will be able to walk a stack with Factor frames. In
> recent versions of Factor you can trigger Factor's own low-level
> debugger with ^C, which will let you backtrace and step through Factor
> frames.
>
> -Joe
>
If I'm understanding this correctly, you are suggesting that if I'm in the
Factor development environment, I can drop into Factor's own low-level
debugger. But what do people do (you language maintainer, for example) when
you need to debug the startup code that builds an image that needs to be in
place for the development environment even to be launched? Am I correctly
understanding you, that I can't use a Windows debugger to step through the init
sequence, but don't have Factor's debugger available yet either? Or am I
missing something? Any insights would be greatly appreciated.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
