This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA/commit+doco 2/2] Windows x64 SEH unwinder.
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