Re: Broken dwarf unwinding - wrong stack pointer register value?

From: Milian Wolff
Date: Tue Oct 23 2018 - 06:34:19 EST


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.

[1]: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?
h=packages/glibc

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

[2]: https://github.com/bminor/glibc/blob/
43b1048ab9418e902aac8c834a7a9a88c501620a/sysdeps/ieee754/dbl-64/e_hypot.c

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

[3]: https://paste.kde.org/poywa7y2z

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/libm.so.6 |& less
...
00002b60 000000000000004c 00002b64 FDE cie=00000000
pc=0000000000029660..00000000000299ce
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_remember_state
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_restore_state
DW_CFA_advance_loc1: 88 to 0000000000029818
DW_CFA_remember_state
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
DW_CFA_restore_state
DW_CFA_nop
```

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?

Thanks
--
Milian Wolff | milian.wolff@xxxxxxxx | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts

Attachment: smime.p7s
Description: S/MIME cryptographic signature