On 05 December 2007 17:25, Christopher Faylor wrote: > I have a vague feeling that I'll regret mentioning this
Oh, I hope not. > but, if you've > built the DLL with --enable-debugging, you can set the CYGWIN_SLEEP > environment variable, to some millisecond value that you want the cygwin > process to sleep for and then attach to the process using 'strace -p'. > > You can also set the CYGWIN_DEBUG variable to the name of the program > that you want to debug to have a debugger popped up when that program > executes. Thanks, I've been looking in that area... static void initial_env () { char buf[CYG_MAX_PATH]; if (GetEnvironmentVariable ("CYGWIN_TESTING", buf, sizeof (buf) - 1)) _cygwin_testing = 1; if (GetEnvironmentVariable ("CYGWIN_STRACE", buf, sizeof (buf) - 1)) { strace.hello (); dk_printf ("dk: found CYGWIN STRACE, hello'd."); } #ifdef DEBUGGING DWORD len; ... along with that patch, I also hacked about strace.hello to auto-activate itself when it spots that the program name contains "cc1plus.exe", which is where I'm getting the problem. I'm currently trying to test the theory that the environment might not be correct inbetween cygwin1 DLL_PROCESS_ATTACH time and application main() invocation when it's >32k. Just in case anyone's curious, I'm finding that an mno-cygwin invocation of g++ turns into an mcygwin invocation of cc1plus, and it occurs to me to wonder if static void set_mingw (void) { char *env = getenv ("GCC_CYGWIN_MINGW"); isn't guaranteed to work when the environment is >32k, owing to set_mingw being called: static void set_mingw (void) __attribute__ ((constructor)); prior to entering main() (and hence without a clear ordering WRT. crt0 process init sequence). cheers, DaveK -- Can't think of a witty .sigline today.... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/