Re: [ITP] stress-ng 0.18.04
On 07/04/2025 16:34, Christian Franke via Cygwin-apps wrote: Jon Turney via Cygwin-apps wrote: On 15/09/2024 16:11, Jon Turney via Cygwin-apps wrote: On 13/09/2024 18:33, Christian Franke via Cygwin-apps wrote: I would like to contribute stress-ng. Also present in Debian, Fedora, FreeBSD, Ubuntu, ... I was thinking about adding a step to our CI to run stress-ng, as it seems quite good at finding some kinds of regressions. I wonder if you could suggest a suitable set of options to invoke it with? Attached is an enhanced version of my local script used to test stress- ng before packaging. I agree that it should provide some more comments :-) Many thanks. I posted the patches to incorporate this in our CI here: https://cygwin.com/pipermail/cygwin-patches/2025q2/013646.html I'm not crazy about using pskill, not least because because it's a bit awkward to get into place. It seems like we should have our own equivalent, but even if implemented, '/usr/bin/kill -f -PGID' seems unlikely to work if the process is hard stuck. (I guess some scripting to grovel over the process tree and /usr/bin/kill -f all the processes with a matching name is possible?) Perhaps the '--keep-name' option should be used, if we're going to kill by process name? I note that the test 'clock' fails in the CI environment: > stress-ng: 23:25:43.13 debug: [1338] invoked with 'stress-ng -v -M --oomable --timestamp --verify --temp-path /cygdrive/c/Users/RUNNER~1/AppData/Local/Temp/stress-ng.1237.5.d -t 5 --log-file /cygdrive/d/a/cygwin/cygwin/logs/clock --clock 2' by user 197108 'runneradmin' > stress-ng: 23:25:43.14 debug: [1338] stress-ng 0.18.12 > stress-ng: 23:25:43.15 debug: [1338] system: CYGWIN_NT-10.0-20348 fv-az-241 3.7.0-api-358.x86_64 2025-04-10 23:13 UTC x86_64, gcc 12.4.0, Cygwin libc, little endian > stress-ng: 23:25:43.15 debug: [1338] RAM total: 16.0G, RAM free: 13.8G, swap free: 2.9G > stress-ng: 23:25:43.15 debug: [1338] temporary file path: '/cygdrive/c/Users/runneradmin/AppData/Local/Temp/stress-ng.1237.5.d' > stress-ng: 23:25:43.15 debug: [1338] 4 processors online, 4 processors configured > stress-ng: 23:25:43.15 info: [1338] setting to a 5 secs run per stressor > stress-ng: 23:25:43.15 debug: [1338] cache allocate: using defaults, cannot determine cache level details > stress-ng: 23:25:43.15 debug: [1338] cache allocate: shared cache buffer size: 2048K > stress-ng: 23:25:43.15 info: [1338] dispatching hogs: 2 clock > stress-ng: 23:25:43.15 debug: [1338] starting stressors > stress-ng: 23:25:43.17 debug: [1338] 2 stressors started > stress-ng: 23:25:43.41 debug: [1340] clock: [1340] started (instance 0 on CPU 2) > stress-ng: 23:25:43.43 debug: [1341] clock: [1341] started (instance 1 on CPU 2) > stress-ng: 00:00:00.-99 fail: [1340] clock: clock_settime was able to set an invalid negative time for timer 'CLOCK_REALTIME' > stress-ng: 00:00:00.-99 fail: [1340] clock: clock_settime was able to set an invalid negative time for timer 'CLOCK_REALTIME_COARSE' > stress-ng: 00:00:00.-99 fail: [1341] clock: clock_settime was able to set an invalid negative time for timer 'CLOCK_REALTIME' > stress-ng: 00:00:00.-99 fail: [1341] clock: clock_settime was able to set an invalid negative time for timer 'CLOCK_REALTIME_COARSE' > stress-ng: 23:25:48.39 debug: [1340] clock: [1340] exited (instance 0 on CPU 2) > stress-ng: 23:25:48.39 error: [1338] clock: [1340] terminated with an error, exit status=2 (stressor failed) > stress-ng: 23:25:48.39 debug: [1338] clock: [1340] terminated (stressor failed) > stress-ng: 23:25:48.40 debug: [1341] clock: [1341] exited (instance 1 on CPU 2) > stress-ng: 23:25:48.40 error: [1338] clock: [1341] terminated with an error, exit status=2 (stressor failed) > stress-ng: 23:25:48.40 debug: [1338] clock: [1341] terminated (stressor failed) > stress-ng: 23:25:48.40 debug: [1338] metrics-check: all stressor metrics validated and sane > stress-ng: 23:25:48.41 metrc: [1338] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s CPU used per RSS Max > stress-ng: 23:25:48.41 metrc: [1338] (secs) (secs)(secs) (real time) (usr+sys time) instance (%) (KB) > stress-ng: 23:25:48.41 metrc: [1338] clock158338 4.97 1.48 7.11 31888.38 18428.5486.52 19992 > stress-ng: 23:25:48.41 info: [1338] skipped: 0 > stress-ng: 23:25:48.41 info: [1338] passed: 0 > stress-ng: 23:25:48.41 info: [1338] failed: 2: clock (2) > stress-ng: 23:25:48.41 info: [1338] metrics untrustworthy: 0 > stress-ng: 23:25:48.41 info: [1338] unsuccessful run completed in 5.25 secs
Re: llvm/clang packages
On Thu, 10 Apr 2025 12:45:06 -0700 (PDT) Jeremy Drake wrote: > We (@mati865 and I) just managed to get llvm/clang 20.1.2 building and > targeting Cygwin over at MSYS2, and I was wondering if you had anyone > interested in these patches to update the package(s) in Cygwin? I'm not > particularly interested in taking on more responsibilities, but I guess I > could take a look at this if nobody else wants to. > > MSYS2 package: > https://github.com/msys2/MSYS2-packages/tree/master/llvm > > Note that we wound up punting on LLD support for Cygwin targets: there's > currently no way to tell the difference in the LLD driver between Cygwin > and MinGW targets, and trying to adapt to Cygwin broke the ability to use > that LLD for MinGW cross-compiling. Given that it was all pretty hacky > anyway, it seemed better to keep the working MinGW cross-compiling support > than trade it in for still-somewhat-broken Cygwin support when we can just > keep using GNU ld for the Cygwin target. Amazing! Now I am trying to build llvm for cygwin. For now, it fails with ld: error: export ordinal too large: x in dll linkage. If you could give me a suggestion, I would greatly appreciate it. -- Takashi Yano
Re: [ITP] stress-ng 0.18.04
Jon Turney wrote: On 07/04/2025 16:34, Christian Franke via Cygwin-apps wrote: Jon Turney via Cygwin-apps wrote: On 15/09/2024 16:11, Jon Turney via Cygwin-apps wrote: On 13/09/2024 18:33, Christian Franke via Cygwin-apps wrote: I would like to contribute stress-ng. Also present in Debian, Fedora, FreeBSD, Ubuntu, ... I was thinking about adding a step to our CI to run stress-ng, as it seems quite good at finding some kinds of regressions. I wonder if you could suggest a suitable set of options to invoke it with? Attached is an enhanced version of my local script used to test stress- ng before packaging. I agree that it should provide some more comments :-) Many thanks. You're welcome. Thanks for accepting the script! I posted the patches to incorporate this in our CI here: https://cygwin.com/pipermail/cygwin-patches/2025q2/013646.html I posted some minor updates/comments. I'm not crazy about using pskill, not least because because it's a bit awkward to get into place. It seems like we should have our own equivalent, but even if implemented, '/usr/bin/kill -f -PGID' seems unlikely to work if the process is hard stuck. Here a very first small step towards an "onboard" tool to stop hanging tests: https://sourceware.org/pipermail/cygwin-patches/2025q2/013651.html A next step could be to add a 'killall' equivalent with '-f' support. For example further enhance Cygwin's kill: /bin/kill --all -f -s - NAME... which then uses only native win32 API to find and stop processes. (I guess some scripting to grovel over the process tree and /usr/bin/kill -f all the processes with a matching name is possible?) Perhaps the '--keep-name' option should be used, if we're going to kill by process name? This is not needed because setproctitle() only changes /proc/PID/cmdline but not /proc/PID/exename: $ stress-ng -v -M --verify --intmath 5 >stress.log & [1] 2268 $ procps -C stress-ng -o pid,ppid,exe,args --sort pid PID PPID EXE COMMAND 2268 1791 /usr/bin/stress-ng stress-ng -v -M --verify --intmath 5 2269 2268 /usr/bin/stress-ng stress-ng-intmath [run] 2270 2268 /usr/bin/stress-ng stress-ng-intmath [run] 2271 2268 /usr/bin/stress-ng stress-ng-intmath [run] 2272 2268 /usr/bin/stress-ng stress-ng-intmath [run] 2273 2268 /usr/bin/stress-ng stress-ng-intmath [run] I note that the test 'clock' fails in the CI environment: ... > stress-ng: 00:00:00.-99 fail: [1340] clock: clock_settime was able to set an invalid negative time for timer 'CLOCK_REALTIME' > stress-ng: 00:00:00.-99 fail: [1340] clock: clock_settime was able to set an invalid negative time for timer 'CLOCK_REALTIME_COARSE' Hmm... interesting. I will have a closer look... -- Regards, Christian
Re: [ITP] stress-ng 0.18.04
On Fri, 11 Apr 2025, Jon Turney via Cygwin-apps wrote: > Many thanks. > > I posted the patches to incorporate this in our CI here: > https://cygwin.com/pipermail/cygwin-patches/2025q2/013646.html > > I'm not crazy about using pskill, not least because because it's a bit awkward > to get into place. Does taskkill /f not work?
Re: llvm/clang packages
On Fri, 11 Apr 2025, Takashi Yano via Cygwin-apps wrote: > On Thu, 10 Apr 2025 12:45:06 -0700 (PDT) > Jeremy Drake wrote: > > We (@mati865 and I) just managed to get llvm/clang 20.1.2 building and > > targeting Cygwin over at MSYS2, and I was wondering if you had anyone > > interested in these patches to update the package(s) in Cygwin? I'm not > > particularly interested in taking on more responsibilities, but I guess I > > could take a look at this if nobody else wants to. > > > > MSYS2 package: > > https://github.com/msys2/MSYS2-packages/tree/master/llvm > > > > Note that we wound up punting on LLD support for Cygwin targets: there's > > currently no way to tell the difference in the LLD driver between Cygwin > > and MinGW targets, and trying to adapt to Cygwin broke the ability to use > > that LLD for MinGW cross-compiling. Given that it was all pretty hacky > > anyway, it seemed better to keep the working MinGW cross-compiling support > > than trade it in for still-somewhat-broken Cygwin support when we can just > > keep using GNU ld for the Cygwin target. > > Amazing! > > Now I am trying to build llvm for cygwin. For now, it fails with > ld: error: export ordinal too large: x > in dll linkage. > > If you could give me a suggestion, I would greatly appreciate it. Are you using the patches and cmake options from https://github.com/msys2/MSYS2-packages/tree/master/llvm ? I noticed one (0101-hack-dynamically-resolve-G-include-dir.patch) has an "msys" that will need to be changed to "cygwin". The export ordinal too large error is because there are too many symbols for export-all-symbols to export from the DLLs (the DLL export table uses an unsigned short, so you only get 65535 exports). With GCC, it can only build static libraries, see https://github.com/msys2/MSYS2-packages/blob/4813abedafbbe1343ca287fded18b14f1f792198/llvm/PKGBUILD#L175-L189 Once you have clang built, you can use it to rebuild llvm with dynamic libs. Clang has a workaround that hooks up ELF-style visibility "hidden" to exclude symbols from auto-export, so there are not too many symbols for a DLL.
Re: llvm/clang packages
On Thu, 10 Apr 2025, Jeremy Drake wrote: > We (@mati865 and I) just managed to get llvm/clang 20.1.2 building and > targeting Cygwin over at MSYS2, and I was wondering if you had anyone > interested in these patches to update the package(s) in Cygwin? I'm not > particularly interested in taking on more responsibilities, but I guess I > could take a look at this if nobody else wants to. > > MSYS2 package: > https://github.com/msys2/MSYS2-packages/tree/master/llvm > > Note that we wound up punting on LLD support for Cygwin targets: there's > currently no way to tell the difference in the LLD driver between Cygwin > and MinGW targets, and trying to adapt to Cygwin broke the ability to use > that LLD for MinGW cross-compiling. Given that it was all pretty hacky > anyway, it seemed better to keep the working MinGW cross-compiling support > than trade it in for still-somewhat-broken Cygwin support when we can just > keep using GNU ld for the Cygwin target. > I tried building on Cygwin (updating one patch to -pc-cygwin from -pc-msys when looking for c++ include dirs), and while the initial build succeeded, rebuilding with clang and dynamic libs fails quickly in llvm-min-tblgen. I have no idea why this would work on MSYS2 but fail in Cygwin (I tried with both the stable gcc 12 and 13.3.1 to better match MSYS2's 13.3.0. Also the 'abort' seems to go away if I build with -DCMAKE_BUILD_TYPE=Debug) (gdb) bt #0 0x7ffdf19b0f34 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll #1 0x7ffdeea76479 in WaitForMultipleObjectsEx () from /cygdrive/c/Windows/System32/KERNELBASE.dll #2 0x7ffdeea7637e in WaitForMultipleObjects () from /cygdrive/c/Windows/System32/KERNELBASE.dll #3 0x7ffda33e688c in cygwait (object=, timeout=timeout@entry=0x7c480, mask=mask@entry=32) at /usr/src/debug/cygwin-3.7.0-0.55.g1c530c37fd63/winsup/cygwin/cygwait.cc:79 #4 0x7ffda345b7d7 in cygwait (mask=32, howlong=6, h=) at /usr/src/debug/cygwin-3.7.0-0.55.g1c530c37fd63/winsup/cygwin/local_includes/cygwait.h:45 #5 sig_send (p=, p@entry=0x1a002, si=..., tls=tls@entry=0x0) at /usr/src/debug/cygwin-3.7.0-0.55.g1c530c37fd63/winsup/cygwin/sigproc.cc:846 #6 0x7ffda34579fe in _pinfo::kill (this=0x1a002, si=...) at /usr/src/debug/cygwin-3.7.0-0.55.g1c530c37fd63/winsup/cygwin/signal.cc:269 #7 0x7ffda3457dd9 in kill0 (si=..., pid=836) at /usr/src/debug/cygwin-3.7.0-0.55.g1c530c37fd63/winsup/cygwin/signal.cc:335 #8 kill (pid=836, sig=) at /usr/src/debug/cygwin-3.7.0-0.55.g1c530c37fd63/winsup/cygwin/signal.cc:346 #9 0x7ffda3457f92 in raise (sig=sig@entry=6) at /usr/src/debug/cygwin-3.7.0-0.55.g1c530c37fd63/winsup/cygwin/signal.cc:307 #10 0x7ffda35a8d28 in abort () at /usr/src/debug/cygwin-3.7.0-0.55.g1c530c37fd63/winsup/cygwin/signal.cc:409 #11 0x7ffda35a8e55 in dlfree (mem=) at /usr/src/debug/cygwin-3.7.0-0.55.g1c530c37fd63/winsup/cygwin/mm/malloc.cc:4780 #12 0x7ffda3510f9a in free ( p=0x100557010 , std::allocator >::_Rep::_S_empty_rep_storage>) at /usr/src/debug/cygwin-3.7.0-0.55.g1c530c37fd63/winsup/cygwin/mm/malloc_wrapper.cc:78 #13 0x7ffda352ca54 in _sigfe () at sigfe.s:35 #14 0x0003fb09c960 in cygstdc++-6!_ZNSs6assignERKSs () from /usr/bin/cygstdc++-6.dll #15 0x0001004e3ab4 in std::basic_string,std::allocator >::operator= (this=0x3, __str="-") at /usr/lib/gcc/x86_64-pc-cygwin/13/include/c++/bits/cow_string.h:728 #16 llvm::cl::opt_storage, std::allocator >, false, true>::setValue, std::allocator > > (this=0x3, V="-", initial=true) at /cygdrive/d/S/llvm/src/llvm/include/llvm/Support/CommandLine.h:1376 #17 llvm::cl::opt, std::allocator >, false, llvm::cl::parser, std::allocator > > >::setInitialValue ( this=0x100557f20 , V="-") at /cygdrive/d/S/llvm/src/llvm/include/llvm/Support/CommandLine.h:1487 #18 llvm::cl::initializer::apply, std::allocator >, false, llvm::cl::parser, std::allocator > > > > ( this=, O=...) at /cygdrive/d/S/llvm/src/llvm/include/llvm/Support/CommandLine.h:433 #19 0x0007cb58 in ?? () #20 0x00010043c8a7 in llvm::cl::getGeneralCategory () at /cygdrive/d/S/llvm/src/llvm/lib/Support/CommandLine.cpp:2664 #21 0x0001004e210e in llvm::cl::applicator >::opt, std::allocator >, false, llvm::cl::parser, std::allocator > > > > (M=..., O=...) at /cygdrive/d/S/llvm/src/llvm/include/llvm/Support/CommandLine.h:1261 #22 llvm::cl::apply, std::allocator >, false, llvm::cl::parser, std::allocator > > >, llvm::cl::initializer > (O=0x100557f20 , M=...) at /cygdrive/d/S/llvm/src/llvm/include/llvm/Support/CommandLine.h:1315 #23 llvm::cl::apply, std::allocator >, false, llvm::cl::parser, std::allocator > > >, llvm::cl::value_desc, llvm::cl::initializer > (O=0x100557f20 , M=..., Ms=...) at /cygdrive/d/S/llvm/src/llvm/include/llvm/Support/CommandLine.h:1311 #24 llvm::cl::apply, std::allocator >, false, llvm::cl::pars
