* Fw: [PATCH] Improve attach on Windows [not found] ` <1549974991.1116105.1750000125453@mail.yahoo.com> @ 2025-06-15 15:10 ` Hannes Domani 2025-06-25 13:31 ` Pedro Alves 1 sibling, 0 replies; 5+ messages in thread From: Hannes Domani @ 2025-06-15 15:10 UTC (permalink / raw) To: Simon Marchi via Gdb-patches Now forwarded to gdb-patches as well. ----- Weitergeleitete Nachricht ----- Von: Hannes Domani <ssbssa@yahoo.de> An: Pedro Alves <pedro@palves.net> Gesendet: Sonntag, 15. Juni 2025 um 17:08:45 MESZ Betreff: Re: [PATCH] Improve attach on Windows Am Mittwoch, 11. Juni 2025 um 23:05:23 MESZ hat Pedro Alves <pedro@palves.net> Folgendes geschrieben: > Unlike most targets, on Windows, when you attach, GDB doesn't print > the current stack frame. Vis: > > On GNU/Linux: > > attach 3340347 > Attaching to program: /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.base/attach/attach, process 3340347 > Reading symbols from /lib/x86_64-linux-gnu/libc.so.6... > Reading symbols from /usr/lib/debug/.build-id/d5/197096f709801829b118af1b7cf6631efa2dcd.debug... > Reading symbols from /lib64/ld-linux-x86-64.so.2... > Reading symbols from /usr/lib/debug/.build-id/9c/b53985768bb99f138f48655f7b8bf7e420d13d.debug... > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > 0x00005b3bf29be174 in main () at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/attach.c:19 > 19 while (! should_exit) > (gdb) PASS: gdb.base/attach.exp: do_attach_tests: attach1, after setting file > > On Cygwin: > > (gdb) attach 6692 > Attaching to program: /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.base/attach/attach, process 6692 > [New Thread 6692.0x2e60] > [New Thread 6692.0x2e9c] > [New Thread 6692.0xd6c] > [New Thread 6692.0x137c] > [New Thread 6692.0x1270] > (gdb) FAIL: gdb.base/attach.exp: do_attach_tests: attach1, after setting file > > On Linux, GDB prints the frame because after the target_attach, GDB > goes back to the event loop, to wait for an initial stop event. The > stop event arrives, and we process it, which sets the stop_print_frame > global, and then we get to normal_stop, which prints the frame iff > stop_print_frame is set, which it is. > > Windows OTOH, is a target_attach_no_wait target, so after > target_attach, there is no going back to event loop. In > infcmd.c:attach_command, we go straight to attach_post_wait which > takes us to normal_stop. But this time, nothing set > stop_print_frame to true, so no frame is printed. Actually, if the > global happened to be true due to an earlier event from debugging a > previous inferior, then we will print the frame. > > This patch makes GDB's behavior consistent, by making sure the globals > normal_stop looks at are in a good state in the target_attach_no_wait > path. > > With that alone, GDB now prints the frame: > > (gdb) attach 2915 > Attaching to program: /usr/bin/sleep.exe, process 2832 > [New Thread 2832.0x2a68] > [New Thread 2832.0xb1c] > [New Thread 2832.0x8ac] > [Switching to Thread 2832.0x8ac] > 0x00007ffec51d4a71 in ntdll!DbgBreakPoint () from C:/Windows/SYSTEM32/ntdll.dll > > This is still not ideal, IMHO, as the current thread is the thread > that Windows injects to attach: > > (gdb) info threads > Id Target Id Frame > 1 Thread 2832.0x2100 "sleep" 0x00007ffec51d18d7 in ntdll!ZwWaitForMultipleObjects () from C:/Windows/SYSTEM32/ntdll.dll > 2 Thread 2832.0x2a68 "sig" 0x00007ffec51d0e47 in ntdll!ZwReadFile () from C:/Windows/SYSTEM32/ntdll.dll > 3 Thread 2832.0xb1c 0x00007ffec51d49d7 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/Windows/SYSTEM32/ntdll.dll > * 4 Thread 2832.0x8ac 0x00007ffec51d4a71 in ntdll!DbgBreakPoint () from C:/Windows/SYSTEM32/ntdll.dll > > Automatically switching to main thread is IMHO more useful. That > results in very similar output than what we see on Linux: > > attach 5164 > Attaching to program: /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.base/attach/attach, process 5164 > [New Thread 5164.0x87c] > [New Thread 5164.0x28f0] > [New Thread 5164.0x376c] > [New Thread 5164.0x2db4] > [New Thread 5164.0xce4] > main () at /home/alves/gdb/src/gdb/testsuite/gdb.base/attach.c:19 > 19 while (! should_exit) > (gdb) I wonder if we should do something similar when Ctrl-C is hit. Regards Hannes ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Improve attach on Windows [not found] ` <1549974991.1116105.1750000125453@mail.yahoo.com> 2025-06-15 15:10 ` Fw: [PATCH] Improve attach on Windows Hannes Domani @ 2025-06-25 13:31 ` Pedro Alves 2025-06-29 17:38 ` Hannes Domani 1 sibling, 1 reply; 5+ messages in thread From: Pedro Alves @ 2025-06-25 13:31 UTC (permalink / raw) To: Hannes Domani, gdb-patches Hi Hannes, [Guess the list was dropped by mistake, adding it back.] On 2025-06-15 16:08, Hannes Domani wrote: >> Automatically switching to main thread is IMHO more useful. That >> results in very similar output than what we see on Linux: >> >> attach 5164 >> Attaching to program: /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.base/attach/attach, process 5164 >> [New Thread 5164.0x87c] >> [New Thread 5164.0x28f0] >> [New Thread 5164.0x376c] >> [New Thread 5164.0x2db4] >> [New Thread 5164.0xce4] >> main () at /home/alves/gdb/src/gdb/testsuite/gdb.base/attach.c:19 >> 19 while (! should_exit) >> (gdb) > > I wonder if we should do something similar when Ctrl-C is hit. > That could be done, I guess. I can think of one downside, but I'm not sure it's strong enough. If you're debugging a program that has a Ctrl-C handler installed, and you decide to pass the exception to the program, after GDB intercepted it, you can do it immediately with "signal SIGINT", or "queue-signal SIGINT; c". But if GDB automatically changes threads, then you have to remember to switch to the thread that got the exception, before issuing the "signal" command. Maybe that could be sorted out with a warning. But then it might be annoying to see the warning all the time. BTW, in the users/palves/windows-non-stop-v2-plus branch, you'll find some extra patches, and this one: commit 95bafb7217bac2d51f5b6a59d34d79bcbaa1eddc Author: Pedro Alves <pedro@palves.net> AuthorDate: Fri May 5 15:51:31 2023 +0100 Commit: Pedro Alves <pedro@palves.net> CommitDate: Mon Jun 9 18:49:19 2025 +0100 Windows all-stop, interrupt with "stopped" instead of SIGTRAP ... is sort of related. It doesn't affect pressing Ctrl-C, but it affects explicit "interrupt", like: (gdb) c& Continuing. (gdb) [New Thread 11688.0x2ff8] [Thread 11688.0x2e30 exited with code 0] [New Thread 11688.0x3040] interrupt (gdb) Thread 1 "sleep" stopped. [Switching to Thread 11688.0x2e94] 0x00007ffd839118d7 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll For Ctrl-C, it might be possible to make GDB see the Ctrl-C before the inferior does, and then stop the inferior with "stopped" too (i.e., just suspend threads, no exception injected.). I still have the Ctrl-C rework series that makes Linux work that way (by making the inferior transparently run on a separate pseudo tty) that I hope I'll eventually be able to get back to. Not sure Windows would need a similar treatment, though, but it might. Pedro Alves ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Improve attach on Windows 2025-06-25 13:31 ` Pedro Alves @ 2025-06-29 17:38 ` Hannes Domani 2025-06-30 22:40 ` Pedro Alves 0 siblings, 1 reply; 5+ messages in thread From: Hannes Domani @ 2025-06-29 17:38 UTC (permalink / raw) To: gdb-patches, Pedro Alves Am Mittwoch, 25. Juni 2025 um 15:32:00 MESZ hat Pedro Alves <pedro@palves.net> Folgendes geschrieben: > Hi Hannes, > > [Guess the list was dropped by mistake, adding it back.] > > On 2025-06-15 16:08, Hannes Domani wrote: > >> Automatically switching to main thread is IMHO more useful. That > >> results in very similar output than what we see on Linux: > >> > >> attach 5164 > >> Attaching to program: /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.base/attach/attach, process 5164 > >> [New Thread 5164.0x87c] > >> [New Thread 5164.0x28f0] > >> [New Thread 5164.0x376c] > >> [New Thread 5164.0x2db4] > >> [New Thread 5164.0xce4] > >> main () at /home/alves/gdb/src/gdb/testsuite/gdb.base/attach.c:19 > >> 19 while (! should_exit) > >> (gdb) > > > > I wonder if we should do something similar when Ctrl-C is hit. > > > > That could be done, I guess. I can think of one downside, but I'm not sure > it's strong enough. If you're debugging a program that has a Ctrl-C handler installed, > and you decide to pass the exception to the program, after GDB intercepted it, you can do > it immediately with "signal SIGINT", or "queue-signal SIGINT; c". But if GDB automatically > changes threads, then you have to remember to switch to the thread that got the exception, > before issuing the "signal" command. Maybe that could be sorted out with a warning. But > then it might be annoying to see the warning all the time. Why would you have to switch threads before "signal", when the signal is anyways handled in a new thread? > BTW, in the users/palves/windows-non-stop-v2-plus branch, you'll find some extra patches, and this one: > > commit 95bafb7217bac2d51f5b6a59d34d79bcbaa1eddc > Author: Pedro Alves <pedro@palves.net> > AuthorDate: Fri May 5 15:51:31 2023 +0100 > Commit: Pedro Alves <pedro@palves.net> > CommitDate: Mon Jun 9 18:49:19 2025 +0100 > > Windows all-stop, interrupt with "stopped" instead of SIGTRAP > > ... is sort of related. It doesn't affect pressing Ctrl-C, but it affects explicit > "interrupt", like: > > (gdb) c& > Continuing. > (gdb) [New Thread 11688.0x2ff8] > [Thread 11688.0x2e30 exited with code 0] > [New Thread 11688.0x3040] > interrupt > > (gdb) > Thread 1 "sleep" stopped. > [Switching to Thread 11688.0x2e94] > 0x00007ffd839118d7 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll > > > For Ctrl-C, it might be possible to make GDB see the Ctrl-C before the inferior does, and then stop > the inferior with "stopped" too (i.e., just suspend threads, no exception injected.). I still have > the Ctrl-C rework series that makes Linux work that way (by making the inferior transparently run on > a separate pseudo tty) that I hope I'll eventually be able to get back to. Not sure Windows would need > a similar treatment, though, but it might. I'm using your Ctrl-C rework series on Linux for years now, and am always wondering why it wasn't merged yet. As for a similar treatment on Windows, I guess this would be possible since Win10, but only needed if "new-console off" (I always use "new-console on"). Hannes ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Improve attach on Windows 2025-06-29 17:38 ` Hannes Domani @ 2025-06-30 22:40 ` Pedro Alves 2025-07-01 16:36 ` Hannes Domani 0 siblings, 1 reply; 5+ messages in thread From: Pedro Alves @ 2025-06-30 22:40 UTC (permalink / raw) To: Hannes Domani, gdb-patches Hi! On 2025-06-29 18:38, Hannes Domani wrote: > Am Mittwoch, 25. Juni 2025 um 15:32:00 MESZ hat Pedro Alves <pedro@palves.net> Folgendes geschrieben: > >> Hi Hannes, >> >> [Guess the list was dropped by mistake, adding it back.] >> >> On 2025-06-15 16:08, Hannes Domani wrote: >>>> Automatically switching to main thread is IMHO more useful. That >>>> results in very similar output than what we see on Linux: >>>> >>>> attach 5164 >>>> Attaching to program: /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.base/attach/attach, process 5164 >>>> [New Thread 5164.0x87c] >>>> [New Thread 5164.0x28f0] >>>> [New Thread 5164.0x376c] >>>> [New Thread 5164.0x2db4] >>>> [New Thread 5164.0xce4] >>>> main () at /home/alves/gdb/src/gdb/testsuite/gdb.base/attach.c:19 >>>> 19 while (! should_exit) >>>> (gdb) >>> >>> I wonder if we should do something similar when Ctrl-C is hit. >>> >> >> That could be done, I guess. I can think of one downside, but I'm not sure >> it's strong enough. If you're debugging a program that has a Ctrl-C handler installed, >> and you decide to pass the exception to the program, after GDB intercepted it, you can do >> it immediately with "signal SIGINT", or "queue-signal SIGINT; c". But if GDB automatically >> changes threads, then you have to remember to switch to the thread that got the exception, >> before issuing the "signal" command. Maybe that could be sorted out with a warning. But >> then it might be annoying to see the warning all the time. > > Why would you have to switch threads before "signal", when the signal > is anyways handled in a new thread? "signal SIG" makes GDB pass "SIG" to the current thread. On Windows, you can only pass a signal to a thread if that thread last stopped for that signal. IOW, on Windows, you can only decide to pass the signal the thread last received, or to suppress it. See windows_nat_target::prepare_resume in the non-stop series, or windows_nat_target::resume in current master, where it reads if (sig != GDB_SIGNAL_0) { if (windows_process.current_event.dwDebugEventCode != EXCEPTION_DEBUG_EVENT) { DEBUG_EXCEPT ("Cannot continue with signal %d here.", sig); } else if (sig == windows_process.last_sig) continue_status = DBG_EXCEPTION_NOT_HANDLED; else So, "signal SIGINT" on a thread that was _not_ the thread that got the CtrlC exception does NOT pass the signal to any thread at all. If the thread that _did_ get the signal is not the selected thread when you issue "signal SIGINT", or, if you didn't use "queue-signal SIGINT" on the thread that got the original CtrlC, then that thread is continued as normal, which means its SIGINT is suppressed. > > >> BTW, in the users/palves/windows-non-stop-v2-plus branch, you'll find some extra patches, and this one: >> >> commit 95bafb7217bac2d51f5b6a59d34d79bcbaa1eddc >> Author: Pedro Alves <pedro@palves.net> >> AuthorDate: Fri May 5 15:51:31 2023 +0100 >> Commit: Pedro Alves <pedro@palves.net> >> CommitDate: Mon Jun 9 18:49:19 2025 +0100 >> >> Windows all-stop, interrupt with "stopped" instead of SIGTRAP >> >> ... is sort of related. It doesn't affect pressing Ctrl-C, but it affects explicit >> "interrupt", like: >> >> (gdb) c& >> Continuing. >> (gdb) [New Thread 11688.0x2ff8] >> [Thread 11688.0x2e30 exited with code 0] >> [New Thread 11688.0x3040] >> interrupt >> >> (gdb) >> Thread 1 "sleep" stopped. >> [Switching to Thread 11688.0x2e94] >> 0x00007ffd839118d7 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll >> >> >> For Ctrl-C, it might be possible to make GDB see the Ctrl-C before the inferior does, and then stop >> the inferior with "stopped" too (i.e., just suspend threads, no exception injected.). I still have >> the Ctrl-C rework series that makes Linux work that way (by making the inferior transparently run on >> a separate pseudo tty) that I hope I'll eventually be able to get back to. Not sure Windows would need >> a similar treatment, though, but it might. > > I'm using your Ctrl-C rework series on Linux for years now, Wow, I never thought anybody would be using that patchset locally, especially as its such an invasive change design wise. Did you ever run into any problems with it? > and am always wondering why it wasn't merged yet. Simply lack of time -- I keep getting pulled into higher priority tasks. The last time I posted it there were a few details raised that I need to address. And then time flies and before you know it a few years have passed. > > As for a similar treatment on Windows, I guess this would be possible since > Win10, but only needed if "new-console off" (I always use "new-console on"). > Right, like on Linux if "set inferior-tty foo" is used GDB doesn't need to do do the pseudo tty dance. I don't recall off hand if on Windows there's a way for the program to suppress CtrlC exceptions completely such that it isn't possible to interrupt the process in GDB with Ctrl-C, similar to the way a program can block SIGINT or use sigwait on Linux, which makes it impossible to interrupt with Ctrl-C. If on Windows, pressing Ctrl-C _always_ makes the kernel inject a new thread for the Ctrl-C exception, then I guess the whole intermediary tty thing (which I guess would be a hidden console on Windows) wouldn't be absolutely needed. Though it may still be nice for other reasons, like having total control of the screen with the TUI. Pedro Alves ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Improve attach on Windows 2025-06-30 22:40 ` Pedro Alves @ 2025-07-01 16:36 ` Hannes Domani 0 siblings, 0 replies; 5+ messages in thread From: Hannes Domani @ 2025-07-01 16:36 UTC (permalink / raw) To: gdb-patches, Pedro Alves Am Dienstag, 1. Juli 2025 um 00:40:28 MESZ hat Pedro Alves <pedro@palves.net> Folgendes geschrieben: > Hi! > > On 2025-06-29 18:38, Hannes Domani wrote: > > Am Mittwoch, 25. Juni 2025 um 15:32:00 MESZ hat Pedro Alves <pedro@palves.net> Folgendes geschrieben: > > > >> Hi Hannes, > >> > >> [Guess the list was dropped by mistake, adding it back.] > >> > >> On 2025-06-15 16:08, Hannes Domani wrote: > >>>> Automatically switching to main thread is IMHO more useful. That > >>>> results in very similar output than what we see on Linux: > >>>> > >>>> attach 5164 > >>>> Attaching to program: /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.base/attach/attach, process 5164 > >>>> [New Thread 5164.0x87c] > >>>> [New Thread 5164.0x28f0] > >>>> [New Thread 5164.0x376c] > >>>> [New Thread 5164.0x2db4] > >>>> [New Thread 5164.0xce4] > >>>> main () at /home/alves/gdb/src/gdb/testsuite/gdb.base/attach.c:19 > >>>> 19 while (! should_exit) > >>>> (gdb) > >>> > >>> I wonder if we should do something similar when Ctrl-C is hit. > >>> > >> > >> That could be done, I guess. I can think of one downside, but I'm not sure > >> it's strong enough. If you're debugging a program that has a Ctrl-C handler installed, > >> and you decide to pass the exception to the program, after GDB intercepted it, you can do > >> it immediately with "signal SIGINT", or "queue-signal SIGINT; c". But if GDB automatically > >> changes threads, then you have to remember to switch to the thread that got the exception, > >> before issuing the "signal" command. Maybe that could be sorted out with a warning. But > >> then it might be annoying to see the warning all the time. > > > > Why would you have to switch threads before "signal", when the signal > > is anyways handled in a new thread? > > "signal SIG" makes GDB pass "SIG" to the current thread. On Windows, you can only pass > a signal to a thread if that thread last stopped for that signal. IOW, on Windows, you > can only decide to pass the signal the thread last received, or to suppress it. > > See windows_nat_target::prepare_resume in the non-stop series, or windows_nat_target::resume > in current master, where it reads > > if (sig != GDB_SIGNAL_0) > { > if (windows_process.current_event.dwDebugEventCode > != EXCEPTION_DEBUG_EVENT) > { > DEBUG_EXCEPT ("Cannot continue with signal %d here.", sig); > } > else if (sig == windows_process.last_sig) > continue_status = DBG_EXCEPTION_NOT_HANDLED; > else > > > So, "signal SIGINT" on a thread that was _not_ the thread that got the CtrlC exception > does NOT pass the signal to any thread at all. If the thread that _did_ get the signal > is not the selected thread when you issue "signal SIGINT", or, if you didn't > use "queue-signal SIGINT" on the thread that got the original CtrlC, then that thread > is continued as normal, which means its SIGINT is suppressed. I didn't know about that limitation, goes to show that I never used the signal command. > > > > > >> BTW, in the users/palves/windows-non-stop-v2-plus branch, you'll find some extra patches, and this one: > >> > >> commit 95bafb7217bac2d51f5b6a59d34d79bcbaa1eddc > >> Author: Pedro Alves <pedro@palves.net> > >> AuthorDate: Fri May 5 15:51:31 2023 +0100 > >> Commit: Pedro Alves <pedro@palves.net> > >> CommitDate: Mon Jun 9 18:49:19 2025 +0100 > >> > >> Windows all-stop, interrupt with "stopped" instead of SIGTRAP > >> > >> ... is sort of related. It doesn't affect pressing Ctrl-C, but it affects explicit > >> "interrupt", like: > >> > >> (gdb) c& > >> Continuing. > >> (gdb) [New Thread 11688.0x2ff8] > >> [Thread 11688.0x2e30 exited with code 0] > >> [New Thread 11688.0x3040] > >> interrupt > >> > >> (gdb) > >> Thread 1 "sleep" stopped. > >> [Switching to Thread 11688.0x2e94] > >> 0x00007ffd839118d7 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll > >> > >> > >> For Ctrl-C, it might be possible to make GDB see the Ctrl-C before the inferior does, and then stop > >> the inferior with "stopped" too (i.e., just suspend threads, no exception injected.). I still have > >> the Ctrl-C rework series that makes Linux work that way (by making the inferior transparently run on > >> a separate pseudo tty) that I hope I'll eventually be able to get back to. Not sure Windows would need > >> a similar treatment, though, but it might. > > > > I'm using your Ctrl-C rework series on Linux for years now, > > Wow, I never thought anybody would be using that patchset locally, especially as its such an invasive change > design wise. Did you ever run into any problems with it? Can't think of any issues at the moment. But the main reason I use it is because the pseudo tty made it possible for me to forward the inferior output to a dedicated TUI window [1]. (nothing fancy, no handling of terminal escape sequences) > > and am always wondering why it wasn't merged yet. > > Simply lack of time -- I keep getting pulled into higher priority tasks. The last time I posted it there were > a few details raised that I need to address. And then time flies and before you know it a few years have passed. > > > > > As for a similar treatment on Windows, I guess this would be possible since > > Win10, but only needed if "new-console off" (I always use "new-console on"). > > > > Right, like on Linux if "set inferior-tty foo" is used GDB doesn't need to do > do the pseudo tty dance. > > I don't recall off hand if on Windows there's a way for the program to suppress > CtrlC exceptions completely such that it isn't possible to interrupt the process > in GDB with Ctrl-C, similar to the way a program can block SIGINT or use sigwait > on Linux, which makes it impossible to interrupt with Ctrl-C. See removing ENABLE_PROCESSED_INPUT flag with SetConsoleMode [2]. But as far as I know it's not possible to suppress Ctrl-Break. > If on Windows, pressing Ctrl-C _always_ makes the kernel inject a new thread for > the Ctrl-C exception, then I guess the whole intermediary tty thing (which I guess would be > a hidden console on Windows) wouldn't be absolutely needed. Though it may still be nice for other > reasons, like having total control of the screen with the TUI. Yes, that would theoretically make a similar TUI window possible. [1] https://github.com/ssbssa/gdb/commit/7407d0214109314e2bb559949a2e8f33e9c001d2 [2] https://learn.microsoft.com/en-us/windows/console/setconsolemode Hannes ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-07-01 16:37 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <1549974991.1116105.1750000125453.ref@mail.yahoo.com>
[not found] ` <1549974991.1116105.1750000125453@mail.yahoo.com>
2025-06-15 15:10 ` Fw: [PATCH] Improve attach on Windows Hannes Domani
2025-06-25 13:31 ` Pedro Alves
2025-06-29 17:38 ` Hannes Domani
2025-06-30 22:40 ` Pedro Alves
2025-07-01 16:36 ` Hannes Domani
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox