Re: [PATCH v3] Windows x64 SEH unwinder

[Tristan Gingold <gingold@adacore.com>]

On Aug 22, 2013, at 6:15 PM, Pedro Alves <palves@redhat.com> wrote:

> On 08/22/2013 04:41 PM, Tristan Gingold wrote:
>> 
>> On Aug 22, 2013, at 5:26 PM, Pedro Alves <palves@redhat.com> wrote:
>> 
>>> On 08/22/2013 10:33 AM, Tristan Gingold wrote:
>>>> 
>>>> after discussion with Roland Schwingel, I have found that the patch
>>>> doesn't handle well dwarf3 DW_OP_call_frame_cfa, because the SEH
>>>> unwinder is before the dwarf2 one.
>>> 
>>> Can you clarify this a little better for the archives?
>> 
>> Sure.
>> 
>>> So that mean that for binaries built before that gcc fix,
>>> the SEH unwinder won't kick in at all, right?
>> 
>> No.
>> If dwarf2 info are presents, they will be used to unwind the
>> frames.  If they aren't, unwinding will probably fail.
> 
> Okay, I ISTR now that the SEH unwinder needs to always kicks
> in, as leaf frames are identified by absence of SEH...  So on
> old binaries without SEH and without dwarf, the SEH unwinder
> will kick in, but the SEH unwinder will probably think all
> functions are leaf, and that naturally most probably fails.

Correct.  But it should be roughly as good as without the SEH
unwinder.

> Good, now we have somewhere archived to point people at
> once someone complains.  :-)
> 
>> 
>>> Then,
>>> how come this fixes Roland's age old issue, and improves
>>> unwinding for him?
>> 
>> For the part compiled with gcc, the patch shouldn't change
>> anything.  But for function compiled by MS compilers (those
>> in dll), gdb will now unwind their frame by using the SEH
>> unwinder,
> 
> Got it.
> 
>> 
>>> In the previous versions, there was talk about needing
>>> finer ordering of the unwinders in order to support both
>>> old and new binaries.  What changed?  Why is this okay
>>> now?
>> 
>> Unwinding was possible when compiled with -g.  It is still
>> possible.
>> Version 1 and 2 of the patch failed, because the dwarf
>> unwinder was never used (always masked by the SEH unwinder).
> 
> I understand that, but what I'm asking is about this discussion
> in v2:
> 
> http://sourceware.org/ml/gdb-patches/2013-01/msg00185.html
> 
> On Jan 9, 2013, at 6:10 PM, Pedro Alves wrote:
>> On 01/09/2013 04:28 PM, Tristan Gingold wrote:
>> 
>>>>> 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.
>>>> 
>>>> What specific finer order where you considering would be needed to
>>>> fix this?
>>> 
>>> Joel once proposed to activate this unwinder if the CU is compiled
>>> by gcc 4.6 or older.
>> 
>> I don't think you need to have a way of more finely ordering
>> the unwinders for that.  AFAICS, we can make the sniffer
>> return false in that case.  I had understood him
>> as meaning something about making the whole prepend/append
>> mechanisms more finer grained somehow.
> 
> So coming from that angle, and seeing that v3 just uses the
> usual prepend/append mechanisms, I naturally get curious on
> whether we're missing something now.
> 
> So IIUC, this new ordering means that even for objects
> compiled with newer gcc's that emit SEH, as long as there's
> dwarf debug info, then GDB won't use the SEH to unwind.

Correct.

> I'm guessing that using SEH if available would
> be better over dwarf2 (though I don't know for sure).

Why ?  I think that both unwinders should be correct. One might
be faster than the other, but I don't know which.

> And, this version is then a compromise.  Right?

The only compromise is when there are no unwind infos.  Previously
a default unwinder based on heuristic was used (doesn't work well,
particularly for MS dll).  With the patch, they are considered as
leaf functions by the SEH unwinder.

> Just trying to understand, and record all this info
> somewhere, not pushing to have it fixed.

Sure. No problem with that.

>> It is still possible that gdb with support for SEH unwinder
>> fails where gdb without for binaries produced by old gcc for
>> the cases where the prologue analyzer using heuristic was
>> correct.  But debugging with this unwinder isn't reliable.
> 
>> 
>> Hopes it clarifies :-)
> 
> Thanks, it does, somewhat.  :-)

Tristan.