This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v3] Windows x64 SEH unwinder
- From: Tristan Gingold <gingold at adacore dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: "gdb-patches at sourceware dot org ml" <gdb-patches at sourceware dot org>, Joel Brobecker <brobecker at adacore dot com>, Roland Schwingel <roland dot schwingel at onevision dot de>
- Date: Fri, 23 Aug 2013 08:53:29 +0200
- Subject: Re: [PATCH v3] Windows x64 SEH unwinder
- References: <1357728781-15073-1-git-send-email-brobecker at adacore dot com> <1357728781-15073-3-git-send-email-brobecker at adacore dot com> <50ED9221 dot 1050504 at redhat dot com> <9E84DF2D-7AF8-4AA1-A5DF-171EF189A6E7 at adacore dot com> <50EDA48E dot 2030406 at redhat dot com> <66611BA9-4536-42B2-A65C-4EA5DA219E22 at adacore dot com> <50EEEB3C dot 9050202 at redhat dot com> <5BE11EDB-7832-4489-8CB1-6382F5D1D34E at adacore dot com> <51F29440 dot 3030808 at redhat dot com> <6F12353E-D32C-40F0-87BF-AA77FC15BE03 at adacore dot com> <52162DA9 dot 5060108 at redhat dot com> <848C81AC-2171-412B-A6F2-101352933F3E at adacore dot com> <52163929 dot 1090008 at redhat dot 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.