Summary: | libunwind temporarily drops a stack frame when stepping between functions | ||
---|---|---|---|
Product: | frysk | Reporter: | Mike Cvet <mcvet> |
Component: | general | Assignee: | Jan Kratochvil <jan> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | aoliva, jan |
Priority: | P2 | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | ||
Bug Depends on: | |||
Bug Blocks: | 1839, 2936, 3076 | ||
Attachments: |
test program
Fix requiring to disable internal caching (included) libunwind-local testcase for debugging Fixed patch, handles signal frames, caching is fixed/unaffected Testcase including signal frame |
Description
Mike Cvet
2006-11-16 18:12:29 UTC
Created attachment 1422 [details]
test program
Created attachment 1430 [details]
Fix requiring to disable internal caching (included)
000000000804848c jump (sp=00000000bff7bfbc)
proc=000000000804848c-00000000080484ba
handler=0 lsda=0
000000000804856e foo+0xa2 (sp=00000000bff7bfc0)
proc=00000000080484cc-0000000008048570
handler=0 lsda=0
00000000080485b3 main+0x43 (sp=00000000bff7bfe0)
proc=0000000008048570-00000000080485c1
handler=0 lsda=0
000000000082fdec __libc_start_main+0xdc (sp=00000000bff7c010)
proc=000000000082fd10-000000000082fded
handler=0 lsda=0
0000000008048401 _start+0x21 (sp=00000000bff7c080)
proc=00000000080483e0-0000000008048402
handler=0 lsda=0
================
000000000804848d jump+0x1 (sp=00000000bff7bfb8)
proc=000000000804848c-00000000080484ba
handler=0 lsda=0
000000000804856e foo+0xa2 (sp=00000000bff7bfc0)
proc=00000000080484cc-0000000008048570
handler=0 lsda=0
00000000080485b3 main+0x43 (sp=00000000bff7bfe0)
proc=0000000008048570-00000000080485c1
handler=0 lsda=0
000000000082fdec __libc_start_main+0xdc (sp=00000000bff7c010)
proc=000000000082fd10-000000000082fded
handler=0 lsda=0
0000000008048401 _start+0x21 (sp=00000000bff7c080)
proc=00000000080483e0-0000000008048402
handler=0 lsda=0
================
000000000804848f jump+0x3 (sp=00000000bff7bfb8)
proc=000000000804848c-00000000080484ba
handler=0 lsda=0
000000000804856e foo+0xa2 (sp=00000000bff7bfc0)
proc=00000000080484cc-0000000008048570
handler=0 lsda=0
00000000080485b3 main+0x43 (sp=00000000bff7bfe0)
proc=0000000008048570-00000000080485c1
handler=0 lsda=0
000000000082fdec __libc_start_main+0xdc (sp=00000000bff7c010)
proc=000000000082fd10-000000000082fded
handler=0 lsda=0
0000000008048401 _start+0x21 (sp=00000000bff7c080)
proc=00000000080483e0-0000000008048402
handler=0 lsda=0
================
Created attachment 1432 [details]
libunwind-local testcase for debugging
There is still needed to make the internal caching compatible with the patch. Still the functionality should be final, I hope. Jan FYI, nice catch, but there's more ... - --ip; + /* In the current (lowest) frame we must not touch `ip' as the current + address is where we stand. On the other hand any upper frames will stand + on the next instruction behind our call which may have a different stack + DWARF information (for `stdcall' called functions) or the next instruction + even may belong already to a different continuing function. */ + if (!c->first_step) + --ip; this can also occure a function was interrupted with a signal at its first instruction giving the layout: inner-most <signal-trampoline> foo-at-first-instruction more generally there are two cases, where the function was interrupted (inner most and caller of signal-trampoline, and others making a normal call Created attachment 1435 [details]
Fixed patch, handles signal frames, caching is fixed/unaffected
Final patch.
Created attachment 1436 [details]
Testcase including signal frame
Testcase still needs to get properly integrated into libunwind testsuite.
Expected output:
00000000080484ec jump (sp=00000000bf90062c)
proc=00000000080484ec-000000000804851a
handler=0 lsda=0
000000000804855d foo+0x31 (sp=00000000bf900630)
proc=000000000804852c-00000000080485d5
handler=0 lsda=0
0000000000eba420 __kernel_sigreturn (sp=00000000bf900650)
proc=0000000000eba41f-0000000000eba428
handler=0 lsda=0
00000000080485d5 lockup (sp=00000000bf90092c)
proc=00000000080485d5-00000000080485da
handler=0 lsda=0
0000000008048632 prefoo+0x58 (sp=00000000bf900930)
proc=00000000080485da-0000000008048634
handler=0 lsda=0
0000000008048697 main+0x63 (sp=00000000bf900960)
proc=0000000008048634-00000000080486a5
handler=0 lsda=0
000000000082fdec __libc_start_main+0xdc (sp=00000000bf900990)
proc=000000000082fd10-000000000082fded
handler=0 lsda=0
0000000008048461 _start+0x21 (sp=00000000bf900a00)
proc=0000000008048440-0000000008048462
handler=0 lsda=0
================
Still not committed - x86_64 signal frames affected by glibc: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217087 Is it enough to get the unwinding fixed in glibc RawHide or should libunwind provide a workaround for legacy glibc releases? I believe RawHide is enough. x86_64 signal frame functionality still dependent on resolving glibc's: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217087 |