Fw: [PATCH] Improve attach on Windows

[Hannes Domani <ssbssa@yahoo.de>]

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