Re: Ordering of unwinders

[Thomas Schwinge <thomas at codesourcery dot com>]

Hello!

On 2010-03-22 14:34, I wrote:
> GDB on ARM Linux (arm-linux-tdep.c) -- and, from a quick glance, a bunch
> of other architectures do similar things -- currently has the following
> series of unwinders configured.  These are tried in turn until the first
> one succeeds.
>
>     arm_linux_restart_syscall_tramp_frame
>     arm_eabi_linux_rt_sigreturn_tramp_frame
>     arm_eabi_linux_sigreturn_tramp_frame
>     arm_linux_rt_sigreturn_tramp_frame
>     arm_linux_sigreturn_tramp_frame
>     arm_stub_unwind
>     dwarf2_frame_unwind
>     dwarf2_signal_frame_unwind
>     arm_prologue_unwind
>
> I'm working on having proper DWARF CFI in glibc for sigreturn frames --
> but that information is never going to be used, as the DWARF unwinders
> are of lower priority than the tramp_frame sniffers.  What's the reason?
>
> Some weeks ago, I had a quick chat with Dan J. about this issue.  He
> couldn't immediatelly think of a reason why the stub one is in front of
> the DWARF unwinders.  Also, he suggested that the tramp_frame sniffers
> should be moved down, so that the DWARF unwinders are on top of the list.
>
> Technically, the tramp_frame unwinders are on the top of the list,
> because they use tramp_frame_*prepend*_unwinder for registering in
> arm-linux-tdep.c:arm_linux_init_abi.  tramp_frame_append_unwinder doesn't
> exist (not yet -- this could be changed easily, of course).
>
> The ordering of the five tramp_frame unwinders doesn't matter, correct?
>
> What to do about arm_stub_unwind -- move it after the DWARF ones?

I guess I understand this a bit better now, the description of
frame-unwind.h:frame_unwind_prepend_unwinder gives a broad hint:
``Register a frame unwinder, _prepending_ it to the front of the search
list (so it is sniffed before previously registered unwinders).  By using
a prepend, later calls can install unwinders that override earlier calls.
This allows, for instance, an OSABI to install a a more specific sigtramp
unwinder that overrides the traditional brute-force unwinder.''

Thus, the tramp_frame unwinders should indeed be placed in front of other
*_sniff_and_guess unwinders.

But where should the DWARF ones be in this game?  Unconditionally in
front of all the ``sniffing / guessing'' unwinders?  This could be done
by adding another category between frame_unwind.c's dummy_frame_unwind /
inline_frame_unwind, and the osabi_head.  Might this be what we should
do?  Is it feasible for all GDB configurations?  That new middle category
would probably also contain the libunwind unwinder (and similar ones),
but I have no actual experience with that.


Regards,
 Thomas

Attachment: pgp00000.pgp
Description: PGP signature