Re: [RFA/commit+doco 2/2] Windows x64 SEH unwinder.

[Tom Tromey <tromey@redhat.com>]

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> I don't think you need to have a way of more finely ordering
Pedro> the unwinders for that.  AFAICS, we can make the sniffer
Pedro> return false in that case.  I had understood him
Pedro> as meaning something about making the whole prepend/append
Pedro> mechanisms more finer grained somehow.

FWIW I think Joel explained it in the original post.

My understanding based on that is that the absence of SEH is normal, but
they'd still like to use this unwinder for such frames, because
amd64-tdep.c provides a catch-all unwinder (I guess amd64_frame_unwind)
that is not always good enough.

It seems to me that there are various possibilities for fixing the
problem though.  For example, the new unwinder could be split into two
parts: one which checks for SEH and one which does not; then arrange
somehow for the checking variant to come before the DWARF unwinders, and
arrange for the non-checking one to come later; and perhaps change
amd64_init_abi so that the Windows code can request that the
unwinder-of-last-resort not be installed.

I don't know the mechanics of arranging the ordering with the DWARF
unwinders.  I couldn't actually figure out how these are installed for
x86-64.

Tom