On 02.08.2012 20:05, Dmitri Shubin wrote:
Hello!
I got strange problem in LuaJIT [1] stack unwinding on Solaris x64.
I wrote minimal test that reproduces the problem:
$ cat main.c
#include <stdio.h>
#include <stdint.h>
typedef struct _Unwind_Exception
{
uint64_t exclass;
void (*excleanup)(int, struct _Unwind_Exception);
uintptr_t p1, p2;
} __attribute__((__aligned__)) _Unwind_Exception;
typedef struct _Unwind_Context _Unwind_Context;
extern uintptr_t _Unwind_GetCFA(_Unwind_Context *);
extern int _Unwind_RaiseException(_Unwind_Exception *);
int
foo_personality(int version, int actions, uint64_t uexclass,
_Unwind_Exception *uex, _Unwind_Context *ctx)
{
char *cfa = (char *) _Unwind_GetCFA(ctx);
printf("cfa = %p\nra = %p\n", cfa, *(void **)(cfa - 8));
}
void
throw()
{
static _Unwind_Exception static_uex;
static_uex.exclass = 0x0102030405060708ULL;
static_uex.excleanup = NULL;
_Unwind_RaiseException(&static_uex);
}
extern void foo(void);
int
main()
{
printf("&main = %p, &foo = %p\n", &main, &foo);
foo();
return 0;
}
$ cat foo.s
.file "foo.s"
.text
.globl foo
.type foo, @function
foo:
call throw
ret
.size foo, .-foo
.section .eh_frame,"a",@unwind
.Lframe1:
.long .LECIE1-.LSCIE1
.LSCIE1:
.long 0
.byte 0x1
.string "zPR"
.uleb128 0x1
.sleb128 -8
.byte 0x10
.uleb128 6
.byte 0x1b
.long foo_personality-.
.byte 0x1b
.byte 0xc
.uleb128 0x7
.uleb128 8
.byte 0x80+0x10
.uleb128 0x1
.align 8
.LECIE1:
.LSFDE2:
.long .LEFDE2-.LASFDE2
.LASFDE2:
.long .LASFDE2-.Lframe1
.long foo-.
.long 6
.uleb128 0
.align 8
.LEFDE2:
First I use GCC (4.7.1 from OpenCSW) to compile both files:
$ /opt/csw/bin/gcc --version | head -1
gcc (GCC) 4.7.1
$ /opt/csw/bin/gcc -m64 main.c foo.s
$ ./a.out
&main = 401834, &foo = 401860
cfa = fffffd7fffdffaf8
ra = 401865
$ gobjdump -dr a.out
...
0000000000401860 <foo>:
401860: e8 a0 ff ff ff callq 401805 <throw>
401865: c3 retq
...
AFAIU here GCC supplied stack unwinder from statically linked libgcc_s
is used and return address for foo context points to somewhere inside foo()
Second I use GCC (gas in fact) to compile foo.s and SunStudio C to
compile main.c and link:
$ cc -V 2>&1 | head -1
cc: Sun C 5.11 SunOS_i386 145355-03 2011/02/11
$ /opt/csw/bin/gcc -m64 -c foo.s
$ cc -m64 main.c foo.o
$ ./a.out
&main = 400b30, &foo = 400b70
cfa = fffffd7fffdffaf0
ra = 400b61
$ gobjdump -dr a.out
...
0000000000400b30 <main>:
400b30: 55 push %rbp
400b31: 48 8b ec mov %rsp,%rbp
400b34: 48 83 ec 10 sub $0x10,%rsp
400b38: 48 c7 c2 70 0b 40 00 mov $0x400b70,%rdx
400b3f: 48 c7 c6 30 0b 40 00 mov $0x400b30,%rsi
400b46: 48 c7 c7 e0 0b 40 00 mov $0x400be0,%rdi
400b4d: b8 00 00 00 00 mov $0x0,%eax
400b52: e8 49 fd ff ff callq 4008a0 <printf@plt>
400b57: b8 00 00 00 00 mov $0x0,%eax
400b5c: e8 0f 00 00 00 callq 400b70 <foo>
400b61: c7 45 fc 00 00 00 00 movl $0x0,-0x4(%rbp)
400b68: 8b 45 fc mov -0x4(%rbp),%eax
400b6b: c9 leaveq
400b6c: c3 retq
400b6d: 00 00 add %al,(%rax)
...
In this case standard Solaris unwinder from libc is used and return
address points to main()
From my understanding of CFA definition given in x86-64 psABI ("the
value of %rsp at the call site in the previous frame." 6.2.5 Context
Management) it looks like value returned by GCC unwinder is wrong.
Am I missing something here?
BTW on Linux (w/ GCC) RA points to foo() as in case 1 so it's
GCC-specific rather than Solaris-specific behavior.
Thanks!
