This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |