Re: [PATCH v3] Windows x64 SEH unwinder

[Pedro Alves <palves@redhat.com>]

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.

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.
I'm guessing that using SEH if available would
be better over dwarf2 (though I don't know for sure).
And, this version is then a compromise.  Right?

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

> 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.  :-)

-- 
Pedro Alves