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

[Eli Zaretskii <eliz@gnu.org>]

> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Joel Brobecker <brobecker@adacore.com>
> Date: Wed,  9 Jan 2013 14:53:01 +0400
> 
> This is the main part of the patch series, which actually
> adds the unwinder.

Thanks!

> One element worth mentioning, perhaps, is the fact that we prepend
> the unwinder, and the sniffer is the default_frame_sniffer which
> always returns 1 (absence of SEH info is normal and means it is
> a leaf function).  This effectively means that all other unwinders
> effectively get shunted. And in particular, I do not think that
> the DWARF unwinder will kick in even if DWARF unwind info is found.
> 
> The problem is that we want to be ahead of the default amd64-tdep
> unwinders, which is kind of a last-resort unwinder doing a good
> job under limited situations only. We'd like to be behind the DWARF
> unwinder if we could, but I don't think there is a way to ensure
> that yet.
> 
> In practice, this shouldn't be a problem, since this unwinder
> has been very reliable for us so far.  But it does assume that
> the compiler is recent enough to generate native SEH data which,
> for GCC, means GCC 4.7 (I have been told). On the other hand,
> it looks like the first GCC release to support x64-windows was
> GCC 4.6.
> 
> I don't really see a real way of supporting both old and new versions
> of GCC, unless we have a way of more finely ordering the unwinders.
> Worse case scenario, we stop supporting code generated by GCC 4.6.
> Or an alternative option is to provide a setting to disable this
> unwinder.

I'm confused: is this change only for 64-bit Windows programs?  If
not, what GCC versions will this support for debugging 32-bit
executables?

> diff --git a/gdb/NEWS b/gdb/NEWS
> index 3451505..d981ac5 100644
> --- a/gdb/NEWS
> +++ b/gdb/NEWS
> @@ -134,6 +134,8 @@ show print type typedefs
>    feature to be enabled.  For more information, see:
>        http://fedoraproject.org/wiki/Features/MiniDebugInfo
>  
> +* GDB can now use Windows x64 unwinding data.
> +

This is OK to go in, but it seems to imply that only 64-bit
executables are affected.  What would it take to do the same on 32-bit
Windows?