Ordering of unwinders

[Thomas Schwinge <thomas@codesourcery.com>]

[-- Attachment #1: Type: text/plain, Size: 1694 bytes --]

Hello!

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 can test these proposed changes on a few system configurations, but not
on the whole spectrum they potentially affect.  (Think: a lot of
different / older kernels, different / older libcs, etc.)

What do you suggest?


Regards,
 Thomas

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]