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

[Pedro Alves <palves@redhat.com>]

On 01/09/2013 05:20 PM, Tom Tromey wrote:
>>>>>> "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.

Thanks.  I hadn't caught the desire to put bits in before the
dwarf unwinder, and other bits after.  I re-read the
original post, and now I read it as always wanting this
unwinder after the DWARF unwinder.  (note: "behind" is
ambiguous to me).  That looks doable with the current
architecture, without splitting the new unwinder, by
appending the non-checking unwinder in amd64_windows_init_abi
before calling amd64_init_abi, and have its sniffer always
claim the frame (which it would anyway), so the fallback
heuristic's sniffer never gets a chance to run.  But I'd
guess before or after dwarf doesn't really matter.

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

Right.  The catch-all unwinders are heuristic, and naturally can't
always work 100% correctly, worse on non-x64 targets,
where we don't have as stiff prologue format requirements.

I got confused with the minimal leaf function handling in the
patch, but this, coupled with __fastcall makes it clearer:

<http://www.sciencezero.org/index.php?title=How_to_write_x64_assembly_functions_in_Visual_C%2B%2B#Leaf_or_frame_function>

"
 leaf functions have limitations:

    Can not call out to other functions
    Can not change any non-volatile registers
    Can not change the stack pointer
"

(It goes without saying, but FAOD, I'd prefer that
explanations to my doubts ended up as comments in the code.)

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

Yeah, it's not obvious.  Put a break on dwarf2_append_unwinders.
The x86-64 gdbarch initialization starts in i386-tdep.c:i386_gdbarch_init,
shared with 32-bit.  There's no amd64_gdbarch_init.  That is what
appends the dwarf unwinders, with the dwarf2_append_unwinders call.
At the bottom, this/a gdbarch init function initializes the osabi (e.g.,
amd64_linux_init_abi), and this is what calls the generic
x86-64 amd64_init_abi early on, and installs the prologue-based
fallback unwinders.

-- 
Pedro Alves