Re: [PATCH] clock_nanosleep(2)

2011-07-31 Thread Corinna Vinschen
Hi Yaakov,

anything new from the clock_nanosleep frontier?

On Jul 21 13:51, Yaakov (Cygwin/X) wrote:
 On Thu, 2011-07-21 at 12:37 +0200, Corinna Vinschen wrote:
  Given our current discussion to change cancelable_wait, does it make
  sense to review this patch?  
 
 No, the cancelable_wait changes need to go first.
 
  AFAICs the clock_nanosleep function will have to be changes quite a bit, 
  right?
 
 Definitely.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat


Re: [PATCH] workaround for sigproc_init

2011-07-31 Thread Corinna Vinschen
On Jul 30 17:04, Christopher Faylor wrote:
 On Fri, Jul 29, 2011 at 08:41:10PM +0900, jojelino wrote:
 As sigproc_init is called during dll initialization, wait_sig thread is 
 not created as soon as possible.(this is known in msdn createthread 
 reference. http://msdn.microsoft.com/en-us/library/ms682453(v=vs.85).aspx)
 And then wait_sig starts to wake up as sig_dispatch_pending enters 
 waitforsingleobject. then main thread stops for few ms. and it shows 
 poor performance.
 
 Incidentally, the intent of the now-defunct wincap
 wincap.has_buggy_thread_startup was to avoid creating wait_sig during
 thread startup, moving it to dll_crt0_1() which is the code that
 eventually calls main().
 
 (This was all rehashed back in August/September 2010)
 
 Although I didn't fiddle with that myself, Corinna reported that having
 the value set had no effect in her test cases so I don't think your
 analysis here is 100% correct.

Erm, I tested on 32 bit.  The slowdown occured on all platforms, not
only 64 bit.  64 bit is still only half as fast in the date loop for
reason or reasons unknown.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat


Re: [PATCH] you can use this patch to profile cygwin

2011-07-31 Thread jojelino

On 2011-07-31 PM 5:26, Corinna Vinschen wrote:

Erm, I tested on 32 bit.  The slowdown occured on all platforms, not
only 64 bit.  64 bit is still only half as fast in the date loop for
reason or reasons unknown.


Corinna

 I used this code to profile every source compiled with -pg 
-finstrument-functions.
It had no documentation. because it existed solely for the purpose to 
breakdown  the cause of slow start.
Existing profiling code has ability to profile single-thread.so it had 
rare useful when the target is cygwin.(it spawns thread.) so i tried 
gaving them to consider threaded environment.
And modified profiling code uses instrument function to profile every 
function enter/exit. eventually, it resulted in terrible performance 
(2.42x slowdown at least)
when the profiling worker is forced to terminated( 
ExitProcess,abort,exit.. ) it notifies worker thread and joins the thread.

Also, i modified initial startup a little bit.

and here is instruction.
# apply patch
for i in thread_profile_stuff.diff thread_profile_core.diff; do patch 
-p0 $i;done;

# pass configure parameter to build cygwin if you didn't configured it.
# make sure that cygwin is configured and can be built. from now i 
copy-paste some bunch of code.
# in i686-pc-cygwin/winsup/cygwin/Makefile, you should add CFLAGS '-pg 
-finstrument-functions' , to make new profiling code effective.
and comment out ifneq ${filter -O%,$(CFLAGS)}  too. it would make 
profiling code functional ( in cases you need to profile cygheap thread 
etc...)

#and use following snippet code to build new cygwin1.dll
s='';for i in boundbuffer pthread instrument kernel32 malloc_wrapper 
pseudo-reloc libstdcxx_wrapper cxx gcrt1 gmon profil mcount; do rm $i.o; 
s=${s} ${i}.o;done;  make CFLAGS='-march=-O2 -g -mfpmath=sse 
-Wno-error=unused-but-set-variable' $s -j 4;make;

#there would be no -pg -finstrument-functions in CFLAGS.
#what this does is, keep some source code from to be profiled.
and done. you got new-cygwin1.dll. rename it and try to discover what is 
the problem. because it gave gmon out like gmon.%pid.%tid.out when 
exited. you would use gprof to see report.

Regards.
? .cproject
? .project
? bc
? bfd
? bootstrap
? build
? conf1732
? conf1732.file
? config.cache
? config.log
? ctype_.i
? erfetch
? fastfetch
? i686-pc-cygwin
? outdiff
? outdiff-onlyprofile
? outdiff-patch
? outdiff-profile
? perl.exe.stackdump
? profile-self
? serdep.tmp
? test
? wincap.h.diff.txt
? winsup.diff
? etc/Makefile
? etc/conf1684subs.awk
? etc/conf1684subs.sh
? etc/config.cache
? etc/config.log
? etc/config.status
? etc/configure.info
? etc/standards.info
? winsup/cygwin/boundbuffer.c
? winsup/cygwin/boundbuffer.h
? winsup/cygwin/config.log
? winsup/cygwin/cppcheck.exe.stackdump
? winsup/cygwin/gcrt1.c
? winsup/cygwin/instrument.c
? winsup/cygwin/instrument.h
? winsup/cygwin/sigfe_base.cc
Index: winsup/cygwin/dcrt0.cc
===
RCS file: /cvs/src/src/winsup/cygwin/dcrt0.cc,v
retrieving revision 1.404
diff -u -r1.404 dcrt0.cc
--- winsup/cygwin/dcrt0.cc  4 Jul 2011 15:25:36 -   1.404
+++ winsup/cygwin/dcrt0.cc  28 Jul 2011 01:49:58 -
@@ -37,7 +37,7 @@
 #include cygxdr.h
 #include fenv.h
 #include ntdll.h
-
+#include profil.h
 #define MAX_AT_FILE_LEVEL 10
 
 #define PREMAIN_LEN (sizeof (user_data-premain) / sizeof 
(user_data-premain[0]))
@@ -648,14 +648,17 @@
   windows_system_directory[windows_system_directory_length++] = L'\\';
   windows_system_directory[windows_system_directory_length] = L'\0';
 }
-
+extern C {
+  void _monstartup2 (void);
+  void _mcleanup (void);
+}
 void __stdcall
 dll_crt0_0 ()
 {
   init_windows_system_directory ();
   init_global_security ();
+  _monstartup2();
   initial_env ();
-
   SetErrorMode (SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
 
   lock_process::init ();
@@ -677,7 +680,6 @@
   device::init ();
   do_global_ctors (__CTOR_LIST__, 1);
   cygthread::init ();
-
   child_proc_info = get_cygwin_startup_info ();
   if (!child_proc_info)
 memory_init (true);
@@ -695,6 +697,7 @@
break;
}
 }
+  atexit (_mcleanup);
 
   user_data-threadinterface-Init ();
 
@@ -723,7 +726,7 @@
 dll_crt0_1 (void *)
 {
   extern void initial_setlocale ();
-
+  sanity_check_profile_thread();
   if (wincap.has_buggy_thread_startup () || dynamically_loaded)
 sigproc_init ();
   check_sanity_and_sync (user_data);
Index: winsup/cygwin/exceptions.cc
===
RCS file: /cvs/src/src/winsup/cygwin/exceptions.cc,v
retrieving revision 1.359
diff -u -r1.359 exceptions.cc
--- winsup/cygwin/exceptions.cc 13 Jul 2011 17:53:21 -  1.359
+++ winsup/cygwin/exceptions.cc 28 Jul 2011 01:49:59 -
@@ -375,7 +375,7 @@
   return 0;
 }
 
-  __small_sprintf (strchr (debugger_command, '\0'),  %u, GetCurrentProcessId 
());
+  __small_sprintf (debugger_command, gdb --pid=%u, GetCurrentProcessId ());
 
   LONG 

Re: [PATCH] you can use this patch to profile cygwin-2

2011-07-31 Thread jojelino

On 2011-07-31 PM 6:16, jojelino wrote:
 # in i686-pc-cygwin/winsup/cygwin/Makefile, you should add CFLAGS '-pg
 -finstrument-functions' , to make new profiling code effective.
 and comment out ifneq ${filter -O%,$(CFLAGS)}  too. it would make
 profiling code functional ( in cases you need to profile cygheap thread
 etc...)
I missed important one.
Please find rule in Makefile and apply following.

# Rule to build cygwin.dll
$(TEST_DLL_NAME): $(LDSCRIPT) dllfixdbg $(DLL_OFILES) $(DLL_IMPORTS) 
$(LIBSERVER) $(LIBC) $(LIBM) $(API_VER) Makefile winver_stamp

$(CXX) $(CXXFLAGS) -Wl,--gc-sections $(nostdlib) -Wl,-T$(firstword $^) \
-Wl,--heap=0 -Wl,--out-implib,cygdll.a -shared -o $@ \
 -e $(DLL_ENTRY) $(DEF_FILE) gcrt1.o $(DLL_OFILES) version.o winver.o \
 $(MALLOC_OBJ) $(LIBSERVER) $(LIBM) $(LIBC) boundbuffer.o instrument.o 
gmon.o mcount.o profil.o /lib/w32api/libkernel32.a \

 -lgcc $(DLL_IMPORTS) -Wl,-Map,cygwin.map
 @$(word 2,$^) $(OBJDUMP) $(OBJCOPY) $@ ${patsubst %0.dll,%1.dbg,$@}
 @ln -f $@ new-$(DLL_NAME)


Re: [PATCH] you can use this patch to profile cygwin

2011-07-31 Thread Christopher Faylor
On Sun, Jul 31, 2011 at 06:16:56PM +0900, jojelino wrote:
On 2011-07-31 PM 5:26, Corinna Vinschen wrote:
 Erm, I tested on 32 bit.  The slowdown occured on all platforms, not
 only 64 bit.  64 bit is still only half as fast in the date loop for
 reason or reasons unknown.


 Corinna

  I used this code to profile every source compiled with -pg 
-finstrument-functions.
It had no documentation. because it existed solely for the purpose to 
breakdown  the cause of slow start.

And, as usual, the formatting is completely off so it couldn't be
incorporated into the source code as is regardless.

Given that this isn't a submitted patch, it probably makes sense to
continue any discussion in cygwin-developers.

cgf