[lkml]   [2018]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Broken dwarf unwinding - wrong stack pointer register value?
On Dienstag, 23. Oktober 2018 06:03:56 CEST Andi Kleen wrote:
> > So what if my libm wasn't compiled with -fasynchronous-unwind-tables? We
> It's default (64bit since always and 32bit now too) Unless someone disabled
> it.

Excellent, good to know. Since [1] doesn't explicitly disable it, I would
assume the information should be available.


> However libm might be partially written in assembler and hand written
> assembler often has problems with unwind tables because the programmer has
> to get them correct explicitely.

Yes, that could be the case. I'm unsure about the glibc build system and what
actually gets compiled, but I found a potential source at [2]:


I believe this is what is used on my system, since I can spot calls to
__issignaling@@GLIBC_2.18 etc. in the disassembly of __hypot_finite ([3]),
which matches the sources referenced in [2].


If [2] is used, then it's not hand written assembler but code compiled by the
compiler. So unwinding should work, even from the prologue?

I have since also figured out how to dump the .eh_frame contents in a human
readable format via readelf. Remember, __hypot_finite on my system is at
offset 0x29660 of libm, so I think the following are the corresponding
.eh_frame contents:

$ readelf --debug-dump=frames /usr/lib/ |& less
00002b60 000000000000004c 00002b64 FDE cie=00000000
DW_CFA_advance_loc: 6 to 0000000000029666
DW_CFA_def_cfa_offset: 16
DW_CFA_offset: r13 (r13) at cfa-16
DW_CFA_advance_loc: 2 to 0000000000029668
DW_CFA_def_cfa_offset: 24
DW_CFA_offset: r12 (r12) at cfa-24
DW_CFA_advance_loc: 1 to 0000000000029669
DW_CFA_def_cfa_offset: 32
DW_CFA_offset: r6 (rbp) at cfa-32
DW_CFA_advance_loc: 6 to 000000000002966f
DW_CFA_def_cfa_offset: 40
DW_CFA_offset: r3 (rbx) at cfa-40
DW_CFA_advance_loc: 29 to 000000000002968c
DW_CFA_def_cfa_offset: 80
DW_CFA_advance_loc2: 291 to 00000000000297af
DW_CFA_def_cfa_offset: 40
DW_CFA_advance_loc: 5 to 00000000000297b4
DW_CFA_def_cfa_offset: 32
DW_CFA_advance_loc: 1 to 00000000000297b5
DW_CFA_def_cfa_offset: 24
DW_CFA_advance_loc: 2 to 00000000000297b7
DW_CFA_def_cfa_offset: 16
DW_CFA_advance_loc: 2 to 00000000000297b9
DW_CFA_def_cfa_offset: 8
DW_CFA_advance_loc: 7 to 00000000000297c0
DW_CFA_advance_loc1: 88 to 0000000000029818
DW_CFA_def_cfa_offset: 40
DW_CFA_advance_loc: 1 to 0000000000029819
DW_CFA_def_cfa_offset: 32
DW_CFA_advance_loc: 1 to 000000000002981a
DW_CFA_def_cfa_offset: 24
DW_CFA_advance_loc: 2 to 000000000002981c
DW_CFA_def_cfa_offset: 16
DW_CFA_advance_loc: 2 to 000000000002981e
DW_CFA_def_cfa_offset: 8
DW_CFA_advance_loc: 18 to 0000000000029830

I notice that this does not touch the rsp register at all, even though it's
mutated by the code, leading to the issue. See again this paste for the
disassembly at [3], and note that the broken sample frame points at

0x0000000000029688 <+40>: sub $0x28,%rsp

Can someone at least confirm whether unwinding from a function prologue via
.eh_frame (but without .debug_frame) should actually be possible?

Milian Wolff | | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts[unhandled content-type:application/pkcs7-signature]
 \ /
  Last update: 2018-10-23 12:35    [W:3.133 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site