summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* cygserver: raise number of worker threads on demandCorinna Vinschen2017-03-242-12/+11
| | | | | | | | | | | | | The number of threads in the worker pool is fixed so far. This is a problem in XSI IPC scenarions with an unknown number of consumers. It doesn't make sense to make the pool very big for a start, but when the need arises, we need to make sure we can serve the request even if all other worker threads are in a wait state. This patch changes threaded_queue to just add another worker thread if all current workers are busy. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* cygserver: Only print basename of source in debug output to raise readabilityCorinna Vinschen2017-03-241-1/+2
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* cygserver: Seralize debug output to stdout to raise readabilityCorinna Vinschen2017-03-241-0/+13
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* dlfcn: Remove stray debug outputnewlib-snapshot-20170323Corinna Vinschen2017-03-222-2/+0
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Rename <sys/_locale.h> to <xlocale.h>Yaakov Selkowitz2017-03-2212-13/+18
| | | | | | | | | The locale_t type is provided by <xlocale.h> on Linux, FreeBSD, and Darwin. While, like on some of those systems, it is automatically included by <locale.h> with the proper feature test macros, its presence under this particular name is still presumed in real-world software. Signed-off-by: Yaakov Selkowitz <yselkowi@redhat.com>
* ARM: Fix IEEE-754 sqrt implementationSebastian Huber2017-03-222-2/+2
| | | | | Older GCC (e.g. 4.9.3) seem to define __ARM_FP even in case soft-float is used.
* ARM: Optimize IEEE-754 sqrt implementationSebastian Huber2017-03-214-1/+108
| | | | Use the vsqrt.f64 and vsqrt.f32 instructions if available.
* Cygwin: dlfcn: Fix reference countingCorinna Vinschen2017-03-213-34/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original dll_init code was living under the wrong assumption that dll_dllcrt0_1 and in turn dll_list::alloc will be called for each LoadLibrary call. The same wrong assumption was made for cygwin_detach_dll/dll_list::detach called via FreeLibrary. In reality, dll_dllcrt0_1 gets only called once at first LoadLibrary and cygwin_detach_dll once at last FreeLibrary. In effect, reference counting for DLLs was completely broken after fork: parent: l1 = dlopen ("lib1"); // LoadLibrary, LoadCount = 1 l2 = dlopen ("lib1"); // LoadLibrary, LoadCount = 2 fork (); // LoadLibrary in the child, LoadCount = 1! child: dlclose (l1); // FreeLibrary actually frees the lib x = dlsym (l2); // SEGV * Move reference counting to dlopen/dlclose since only those functions have to keep track of loading/unloading DLLs in the application context. * Remove broken accounting code from dll_list::alloc and dll_list::detach. * Fix error handling in dlclose. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* libc/string/strsignal.c: Use of || not && lead to dead code.Joel Sherrill2017-03-151-4/+2
| | | | Coverity Id: 175333
* rtems/crt0.c: getentropy() stub did not return a value.Joel Sherrill2017-03-151-1/+1
| | | | Coverity Scan ID: 175342
* Add release message for commit 973f766f6Corinna Vinschen2017-03-141-0/+3
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Revert "Add release message for commit 973f766f6"Corinna Vinschen2017-03-142-6/+12
| | | | | | This reverts commit 125852d77b65fe2155d0d5fa97e53fc9e2b29984. Accidentally commited too much.
* Add release message for commit 973f766f6Corinna Vinschen2017-03-142-12/+6
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Fix duplocale (libc/locale/duplocale.c) which fails to properly call ↵Koichi Murase2017-03-132-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | __loadlocale Problem: After passing locales created by 'duplocale' to 'uselocale', referencing 'MB_CUR_MAX', which is actually expanded to '__locale_mb_cur_max()' by preprocessors, causes segmentation faults. Direct use of locales from 'newlocale' does not cause the problem. This is the problem of 'duplocale'. $ echo $LANG ja_JP.UTF-8 $ cat test.c #include <stdlib.h> #include <locale.h> volatile int var; int main(void) { locale_t const loc = newlocale(LC_ALL_MASK, "", NULL); locale_t const dup = duplocale(loc); locale_t const old = uselocale(dup); var = MB_CUR_MAX; /* <-- crashes here */ uselocale(old); freelocale(dup); freelocale(loc); return 0; } $ gcc test.c $ ./a Segmentation fault (core dumped) # Note: "core dumped" in the above message was actually written in # Japanese, but I translated the part to post a mail in English. Bug: In the beginning of '__loadlocale' (newlib/libc/locale/locale.c:501), there is a code which checks if the operations can be skipped: > /* Avoid doing everything twice if nothing has changed. */ > if (!strcmp (new_locale, loc->categories[category])) > return loc->categories[category]; While, in the function '_duplocale_r' (newlib/libc/locale/ duplocale.c), '__loadlocale' is called as in the quoted codes: > /* If the object is not a "C" locale category, copy it. Just call > __loadlocale. It knows what to do to replicate the category. */ > tmp_locale.lc_cat[i].ptr = NULL; > tmp_locale.lc_cat[i].buf = NULL; > if (!__loadlocale (&tmp_locale, i, tmp_locale.categories[i])) > goto error; This call of '__loadlocale' results in the skip check being !strcmp(tmp_locale.categories[i], tmp_locale.categories[i]), which is always true. This means that the actual operations of '__loadLocale' will never be performed for 'duplocale'. Fix: The call of '__loadlocale' in '_duplocale_r' is modified. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Extend 2.8.0 release textCorinna Vinschen2017-03-121-0/+5
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Implement fhandler_dev_null::write to workaround a problem with NULCorinna Vinschen2017-03-122-0/+11
| | | | | | | | Windows NUL device returns only the lower 32 bit of the number of bytes written. Implement a fake write function to ignore the underlying NUL device. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Return value from write is ssize_t, not intCorinna Vinschen2017-03-121-1/+1
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* getrandom: it's MIN, not MAXYaakov Selkowitz2017-03-112-1/+3
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Belatedly bump Cygwin DLL version to 2.8.0Corinna Vinschen2017-03-103-2/+35
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Drop now unused child_info_fork::from_mainCorinna Vinschen2017-03-101-2/+1
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* fork: Don't copy _main_tls->local_clib from *_impure_ptrCorinna Vinschen2017-03-101-7/+2
| | | | | | | | | | | So far we copy *_impure_ptr into _main_tls->local_clib if the child process has been forked from a pthread. But that's not required. The local_clib area of the new thread is on the stack and the stack gets copied from the parent anyway (in frok::parent). So we only have to make sure _main_tls is pointing to the right address and do the simple post-fork thread init. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* _dll_crt0: Drop incorrect check for being started from parent main threadCorinna Vinschen2017-03-101-1/+1
| | | | | | | | | | | This test was broken from the start. It leads to creating a completely new stack for the main thread of the child process when started from the main thread of the parent. However, the main thread of a process can easily running on a completely different stack, if the parent's main thread was created by calling fork() from a pthread. For an example, see https://cygwin.com/ml/cygwin/2017-03/msg00113.html Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* errno: Stop using _impure_ptr->_errno completelyCorinna Vinschen2017-03-103-6/+5
| | | | | | | | We use errno AKA _REENT->_errno since the last century and only set _impure_ptr->_errno for backward compat. Stop that. Also, remove the last check for _impure_ptr->_errno in Cygwin code. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Drop redundant brackets in call to _reclaim_reentCorinna Vinschen2017-03-101-1/+1
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Implement dladdr() (partially)Jon Turney2017-03-086-1/+61
| | | | | | | Note that this always returns with dli_sname and dli_saddr set to NULL, indicating no symbol matching addr could be found. Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
* yield: Don't lower thread priority, it leads to starvationCorinna Vinschen2017-03-081-5/+6
| | | | | | | ...and it's not required anymore to have the same effect as the original code post-XP. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: Emit correct errno EAGAIN if we can't create another threadCorinna Vinschen2017-03-081-0/+2
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Export timingsafe_bcmp and timingsafe_memcmpJon Turney2017-03-074-1/+7
| | | | Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
* Document pthread_cond_wait change in release notesCorinna Vinschen2017-03-071-0/+3
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: pthread_cond_wait: Do as Linux and BSD do.Corinna Vinschen2017-03-071-22/+5
| | | | | | | | | | | | | | | POSIX states as follows about pthread_cond_wait: If a signal is delivered to a thread waiting for a condition variable, upon return from the signal handler the thread resumes waiting for the condition variable as if it was not interrupted, or it returns zero due to spurious wakeup. Cygwin so far employs the latter behaviour, while Linux and BSD employ the former one. Align Cygwin behaviour to Linux and BSD. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* cwdstuff: Don't leave from setting the CWD prematurely on initCorinna Vinschen2017-03-031-8/+42
| | | | | | | | | | | | | | | | | | | | There are certain, very obscure scenarios, which render the Windows CWD handle inaccessible for reopening. An easy one is, the handle can be NULL if the permissions of the CWD changed under the parent processes feet. Originally we just set errno and returned, but in case of init at process startup that left the "posix" member NULL and subsequent calls to getcwd failed with EFAULT. We now check for a NULL handle and change the reopen approach accordingly. If that doesn't work, try to duplicate the handle instead. If duplicating fails, too, we set the dir handle to NULL and carry on. This will at least set posix to some valid path and subsequent getcwd calls won't fail. A NULL dir handle is ok, because we already do this for virtual paths. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Preserve order of dlopen'd modules in dll_list::topsortnewlib-snapshot-20170228David Allsopp2017-02-283-5/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch alters the behaviour of dll_list::topsort to preserve the order of dlopen'd units. The load order of unrelated DLLs is reversed every time fork is called, since dll_list::topsort finds the tail of the list and then unwinds to reinsert items. My change takes advantage of what should be undefined behaviour in dll_list::populate_deps (ndeps non-zero and ndeps and deps not initialised) to allow the deps field to be initialised prior to the call and appended to, rather than overwritten. All DLLs which have been dlopen'd have their deps list initialised with the list of all previously dlopen'd units. These extra dependencies mean that the unwind preserves the order of dlopen'd units. The motivation for this is the FlexDLL linker used in OCaml. The FlexDLL linker allows a dlopen'd unit to refer to symbols in previously dlopen'd units and it resolves these symbols in DllMain before anything else has initialised (including the Cygwin DLL). This means that dependencies may exist between dlopen'd units (which the OCaml runtime system understands) but which Windows is unaware of. During fork, the process-level table which FlexDLL uses to get the symbol table of each DLL is copied over but because the load order of dlopen'd DLLs is reversed, it is possible for FlexDLL to attempt to access memory in the DLL before it has been loaded and hence it fails with an access violation. Because the list is reversed on each call to fork, it means that a subsequent call to fork puts the DLLs back into the correct order, hence "even" invocations of fork work! An interesting side-effect is that this only occurs if the DLLs load at their preferred base address - if they have to be rebased, then FlexDLL works because at the time that the dependent unit is loaded out of order, there is still in memory the "dummy" DONT_RESOLVE_DLL_REFERENCES version of the dependency which, as it happens, will contain the correct symbol table in the data section. For my tests, this initially appeared to be an x86-only problem, but that was only because the two DLLs on x64 should have been rebased. Signed-off-by: David Allsopp <david.allsopp@metastack.com>
* Add 2.7.1 release fileCorinna Vinschen2017-02-241-0/+14
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Generate output with Unix line endings even from Mingw64 utilsCorinna Vinschen2017-02-242-0/+8
| | | | | | This affects cygcheck and strace. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Bump Cygwin version to 2.7.1Corinna Vinschen2017-02-241-1/+1
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* fix parallel build for version.cc and winver.oMichael Haubenwallner2017-02-161-1/+3
| | | | Creating both version.cc and winver.o at once really should run once only.
* Update makedocbook for bd547490Jon Turney2017-02-151-3/+4
| | | | | | | | Teach makedocbook how to handle some new things seen in the makedoc markup since bd547490: - struct lines appearing in the synopsis - use of @strong{} texinfo markup
* Fix elf-nano.specs to work without -save-tempsThomas Preud'homme2017-02-151-3/+3
| | | | | | | | | | | | The changes in af272aca591fe1dc0f1be64ae5bda147ea98a047 only works when using gcc/g++ with -E or -save-temps, otherwise newlib's newlib.h gets used even if -specs=nano.specs is specified. This is because the driver only use cpp_options spec for the external cpp tool, not for the integrated one. This patch uses instead cpp_unique_options which is used in all cases: it is used directly when the integrated preprocessor is used, and indirectly by expansion of cpp_options otherwise.
* Improve wording on special charactersKenneth Nellis2017-02-141-1/+2
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Allow locking routine to be retargetedThomas Preud'homme2017-02-1310-14/+316
| | | | | | | | | | | | | | | | | | | | | | | | | | | | At the moment when targeting bare-metal targets or systems without definition for the locking primitives newlib, uses dummy empty macros. This has the advantage of reduced size and faster implementation but does not allow the application to retarget the locking routines. Retargeting is useful for a single toolchain to support multiple systems since then it's only at link time that you know which system you are targeting. This patch adds a new configure option --enable-newlib-retargetable-locking to use dummy empty functions instead of dummy empty macros. The default is to keep the current behavior to not have any size or speed impact on targets not interested in this feature. To allow for any size of lock, the _LOCK_T type is changed into pointer to struct _lock and the _init function are tasked with allocating the locks. The platform being targeted must provide the static locks. A dummy implementation of the locking routines and static lock is provided for single-threaded applications to link successfully out of the box. To ensure that the behavior is consistent (either no locking whatsoever or working locking), the dummy implementation is strongly defined such that a partial retargeting will cause a doubly defined link error. Indeed, the linker will only pull in the file providing the dummy implementation if it cannot find an implementation for one of the routine or lock.
* Only define static locks in multithreaded modeThomas Preud'homme2017-02-135-6/+28
| | | | | | | | | | | | | Newlib build system defines __SINGLE_THREAD__ to allow concurrency code to be only compiled when newlib is configured for multithread. One such example are locks which become useless in single thread mode. Although most static locks are indeed guarded by !defined(__SINGLE_THREAD__), some are not. This commit adds these missing guards to __dd_hash_mutex, __atexit_recursive_mutex, __at_quick_exit_mutex and __arc4random_mutex. It also makes sure locking macros in lock.h are noop in single thread mode.
* Fix cpp invocation for C++ in nano specThomas Preudhomme2017-02-131-3/+3
| | | | | | | | | | | Hi, The changes in c028685518a261f6d0dab0d7ed15f9570ab9b3d0 to use newlib-nano's include directory work for cc1 but not cc1plus. cc1plus comes with its own cpp spec which does not have a name attached to it. This patch uses the renaming trick on cpp_options instead of cpp, as cpp_options is used both by cc1 and cc1plus.
* libgloss: Remove duplicate definition of environStafford Horne2017-02-131-3/+0
| | | | | | | | | | | | | | | | Environ is defined in libgloss and libc: - libgloss/or1k/syscalls.c - libc/stdlib/environ.c When linking we sometimes get errors: or1k-elf-g++ test.o -mnewlib -mboard=or1ksim -lm -o test /opt/shorne/software/or1k/lib/gcc/or1k-elf/5.3.0/../../../../or1k-elf/lib/libor1k.a(syscalls.o):(.data+0x0): multiple definition of `environ' /opt/shorne/software/or1k/lib/gcc/or1k-elf/5.3.0/../../../../or1k-elf/lib/libc.a(lib_a-environ.o):(.data+0x0): first defined here collect2: error: ld returned 1 exit status This doesnt happen after the fix. Basic things build fine too.
* libgloss: or1k: If available call the init for init_arrayStafford Horne2017-02-131-0/+6
| | | | | | | | | There was an issue revealed in gdb testing where C++ virtual tables were not getting properly initialized. This seems to be due to the c++ global constructors moving from ctors to init_array. This fix makes sure we call the proper method for initializing the constructors in all places.
* or1k: Make open reentrantOlof Kindgren2017-02-131-1/+1
| | | | | | | | | | | or1k uses reentrant calls by default, but there was no open_r defined which caused failure in C++/C code such as: int main() { std::cout << "test\n"; return 0; } or int main() {open(".", 0);}
* Add IBM Security Trusteer Rapport to BLODA listcygwin-2_7_0-releaseCorinna Vinschen2017-02-121-0/+1
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: create separate bits/byteswap.hYaakov Selkowitz2017-02-083-37/+51
| | | | | | | | Match glibc behaviour to expose the public bswap_* macros only with an explicity #include <byteswap.h>; #include'ing <endian.h> should not expose them. Signed-off-by: Yaakov Selkowitz <yselkowi@redhat.com>
* Unify names of all lock objectsFreddie Chopin2017-02-069-40/+40
| | | | | | | | | | | | | | | | | | In preparation for the patch that would allow retargeting of locking routines, rename all lock objects to follow this pattern: "__<name>_[recursive_]mutex". Following locks were renamed: __dd_hash_lock -> __dd_hash_mutex __sfp_lock -> __sfp_recursive_mutex __sinit_lock -> __sinit_recursive_mutex __atexit_lock -> __atexit_recursive_mutex _arc4random_mutex -> __arc4random_mutex __env_lock_object -> __env_recursive_mutex __malloc_lock_object -> __malloc_recursive_mutex __atexit_mutex -> __at_quick_exit_mutex __tz_lock_object -> __tz_mutex
* Make anchors stable in generated Cygwin HTML documentationJon Turney2017-02-064-63/+63
| | | | | | | Give more elements ids, so random ids aren't assigned to them, so anchors are stable between builds. Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
* Add release message for commit 609d2b2Corinna Vinschen2017-02-031-0/+3
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-17 09:32:32 +0000