summaryrefslogtreecommitdiff
path: root/libcrypt/Makefile.in
diff options
context:
space:
mode:
authorMax Filippov <jcmvbkbc@gmail.com>2016-02-22 07:08:10 +0300
committerWaldemar Brodkorb <wbx@uclibc-ng.org>2016-02-24 22:17:10 +0100
commitc8d441345fb301e6f5aa828f217d377dbc4f252b (patch)
tree81753294781e5ead6cdcc8eed316e45f74a8c241 /libcrypt/Makefile.in
parenta3bc533a1afb73ca9cae97440008fa7d1c8765b6 (diff)
xtensa: fix stack unwinding over __default_sa_restorer
For some xtensa cores generated code gets arranged so that __default_sa_restorer immediately follows preceding function. E.g.: 40a1b: c03340 sub a3, a3, a4 40a1e: f01d retw.n 00040a20 <__default_sa_restorer>: 40a20: e1a022 movi a2, 225 40a23: 005000 syscall ... Contents of the .eh_frame section: ... 000007f4 00000014 000007f8 FDE cie=00000000 pc=0004076c..00040a20 DW_CFA_advance_loc4: 3 to 0004076f DW_CFA_def_cfa_offset: 48 Due to the way xtensa libgcc uw_frame_state_for calls _Unwind_Find_FDE for non-signal frames, FDE for the previous function is found during thread cancellation signal stack unwinding in that case. Signal stack frame is not recognized and is not unwound properly, breaking cleanup routines calling for cancelled thread. Insert padding before the __default_sa_restorer so that no FDE is found for it, MD_FALLBACK_FRAME_STATE_FOR is called by uw_frame_state_for and the frame is correctly recognized as signal frame. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Diffstat (limited to 'libcrypt/Makefile.in')
0 files changed, 0 insertions, 0 deletions