Ordering of unwinders

Ordering of unwinders

[Thomas Schwinge]

[-- 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 --]

Re: Ordering of unwinders

[Thomas Schwinge]

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

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 #2: Type: application/pgp-signature, Size: 196 bytes --]