]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
Teach gdb how to unwind cygwin _sigbe and sigdelayed frames
authorJon Turney <jon.turney@dronecode.org.uk>
Tue, 12 Jan 2016 22:49:09 +0000 (22:49 +0000)
committerPedro Alves <pedro@palves.net>
Fri, 23 Feb 2024 16:16:18 +0000 (16:16 +0000)
commitff4e23032673f78177d5d47e7e9812238eaa6553
tree591f322cb442f6fc8143dd1e52b42a6da092a048
parente346d50a89106a52fa1545db5eade2a25a4932f0
Teach gdb how to unwind cygwin _sigbe and sigdelayed frames

The majority of functions in the cygwin DLL are wrapped by routines
which use an an alternate stack to return via a signal handler if a
signal occured while inside the function. (See [1],[2])

At present, these frames cannot be correctly unwound by gdb.  There
doesn't seem to currently be a way to correctly describe these frames
using DWARF CFI.

So instead, write a custom unwinder for _sigbe and sigdelayed frames,
which gets the return address from the alternate stack.

The offset of tls::stackptr from TIB.stacktop is determined by analyzing
the code in _sigbe or sigdelayed.

This can backtrace from _sigbe and from a sighandler through sigdelayed.

Implemented for amd64 and i386

Issues:

1. We should detect if we are in the wrapper after the return address
has been popped off the alternate stack, and if so, fetch the return
address from the register it's been popped into.

2. If there are multiple _sigbe or sigdelayed stack frames to be
unwound, this only unwinds the first one correctly, because we don't
unwind the value of the alternate stack pointer itself.

This is no worse than currently, when we can't even unwind one of
these frame correctly, but isn't quite correct.

I guess this could be handled by defining a pseudo-register to track
its value as we unwind the stack.

[1] https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/gendef
[2] https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/how-signals-work.txt

Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: I4a0d02c1b85d0aadaab2de3abd584eb4bda5b5cc
gdb/amd64-windows-tdep.c
gdb/i386-windows-tdep.c
gdb/windows-tdep.c
gdb/windows-tdep.h