[v2,02/11] Adjust gdb.base/exitsignal.exp for MinGW, second-chance SIGSEGV
Checks
| Context |
Check |
Description |
| linaro-tcwg-bot/tcwg_gdb_build--master-arm |
success
|
Build passed
|
| linaro-tcwg-bot/tcwg_gdb_build--master-aarch64 |
success
|
Build passed
|
| linaro-tcwg-bot/tcwg_gdb_check--master-arm |
success
|
Test passed
|
| linaro-tcwg-bot/tcwg_gdb_check--master-aarch64 |
success
|
Test passed
|
Commit Message
On native Windows a segmentation fault is delivered as a SEH
exception, so GDB stops twice: once for the first-chance exception,
and -- if no SEH handler in the inferior catches it -- again for the
second-chance exception, after which the process dies. The testcase
currently continues only once, resulting in:
...
continue
Continuing.
Thread 1 received signal SIGSEGV, Segmentation fault.
0x00007ff765ac1469 in main (argc=1, argv=0x9f2640) at C:/rocgdb/src.cascais-rsync/gdb/testsuite/gdb.base/segv.c:24
24 *(volatile int *) 0;
(gdb) PASS: gdb.base/exitsignal.exp: trigger SIGSEGV
continue
Continuing.
Thread 1 received signal SIGSEGV, Segmentation fault.
0x00007ff765ac1469 in main (argc=1, argv=0x9f2640) at C:/rocgdb/src.cascais-rsync/gdb/testsuite/gdb.base/segv.c:24
24 *(volatile int *) 0;
(gdb) FAIL: gdb.base/exitsignal.exp: program terminated with SIGSEGV
...
Add a second continue on MinGW to step past the second-chance stop.
With this, gdb.base/exitsignal.exp passes cleanly on MinGW:
-FAIL: gdb.base/exitsignal.exp: program terminated with SIGSEGV
+PASS: gdb.base/exitsignal.exp: trigger SIGSEGV, second-chance
+PASS: gdb.base/exitsignal.exp: program terminated with SIGSEGV
Change-Id: Ibda1540a602b62c26a5b218d930402eccc3ba98f
commit-id: 385755c8
---
gdb/testsuite/gdb.base/exitsignal.exp | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
Comments
> From: Pedro Alves <pedro@palves.net>
> Date: Mon, 25 May 2026 20:18:20 +0100
>
> On native Windows a segmentation fault is delivered as a SEH
> exception
Is this correct for all native Windows targets, including 32-bit x86,
or only for x86_64?
Hi!
On 2026-05-26 12:18, Eli Zaretskii wrote:
>> From: Pedro Alves <pedro@palves.net>
>> Date: Mon, 25 May 2026 20:18:20 +0100
>>
>> On native Windows a segmentation fault is delivered as a SEH
>> exception
>
> Is this correct for all native Windows targets, including 32-bit x86,
> or only for x86_64?
>
Yes. SEH is the Windows OS-level exception mechanism and has been part of NT since 3.1. Windows 95 had it too.
On every supported architecture.
On Windows, an access violation is turned by the kernel into an EXCEPTION_RECORD with code EXCEPTION_ACCESS_VIOLATION and dispatched through SEH.
16-bit Windows had no such luck, but we don't support that.
Are you perhaps thinking of table-based SEH in x86-64 vs the linked-list style that existed in 32-bit x86?
Both schemes are still SEH. GDB sees the same first/second-chance pair for a null deref whether the inferior is 32-bit or 64-bit Win32.
Pedro Alves
@@ -53,7 +53,13 @@ gdb_test "print \$_exitcode" " = void" \
gdb_test "continue" "(Thread .*|Program) received signal SIGSEGV.*" \
"trigger SIGSEGV"
-if {[istarget "*-*-cygwin*"]} {
+if {[istarget "*-*-mingw*"]} {
+ # We're debugging a pure Win32 program with no SEH handler. The
+ # previous continue caught the first-chance exception. Now we
+ # catch the second-chance.
+ gdb_test "continue" "Thread .* received signal SIGSEGV.*" \
+ "trigger SIGSEGV, second-chance"
+} elseif {[istarget "*-*-cygwin*"]} {
# Cygwin calls DebugBreak before it lets the process exit.
gdb_test "continue" "Thread .* received signal SIGTRAP.*" \
"trigger try_to_debug SIGTRAP"