This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
tst-backtrace failures on AArch64
- From: Will Newton <will dot newton at linaro dot org>
- To: libc-alpha <libc-alpha at sourceware dot org>
- Date: Mon, 11 Aug 2014 11:59:30 +0100
- Subject: tst-backtrace failures on AArch64
- Authentication-results: sourceware.org; auth=none
Hi all,
On AArch64 tst-backtrace5 and tst-backtrace6 fail. The test output is
as follows:
Obtained backtrace with 7 functions
Function 0: /home/will/glibc-build/debug/tst-backtrace5(handle_signal+0x20)
[0x401c78]
Function 1: linux-vdso.so.1(__kernel_rt_sigreturn+0) [0x20000004d0]
Function 2: /home/will/glibc-build/libc.so.6(+0xbb6f8) [0x20000bf6f8]
Function 3: /home/will/glibc-build/debug/tst-backtrace5(fn+0xc4) [0x401f24]
Function 4: /home/will/glibc-build/debug/tst-backtrace5(fn+0x20) [0x401e80]
Function 5: /home/will/glibc-build/debug/tst-backtrace5(fn+0x20) [0x401e80]
Function 6: /home/will/glibc-build/debug/tst-backtrace5() [0x401f68]
Failure on line 83
The failure is called by no call to "read" being found in the call stack:
76 /* Do not check name for signal trampoline. */
77 i = 2;
78 if (!match (symbols[i++], "read"))
79 {
80 /* Perhaps symbols[2] is __kernel_vsyscall? */
81 if (!match (symbols[i++], "read"))
82 {
83 FAIL ();
84 return;
85 }
86 }
Looking at the addresses found in the call stack 0xbb6f8 is actually
in __read_nocancel:
00000000000bb6f0 <__read_nocancel>:
bb6f0: d28007e8 mov x8, #0x3f // #63
bb6f4: d4000001 svc #0x0
bb6f8: b13ffc1f cmn x0, #0xfff
bb6fc: 54000042 b.cs bb704 <__read_nocancel+0x14>
bb700: d65f03c0 ret
bb704: 17fd95aa b 20dac <__GI___syscall_error>
bb708: d503201f nop
bb70c: d503201f nop
00000000000bb710 <__read>:
bb710: f0000450 adrp x16, 146000
<__libc_pthread_functions+0x68>
bb714: b9414e10 ldr w16, [x16,#332]
bb718: 34fffed0 cbz w16, bb6f0 <__read_nocancel>
Which is a local symbol and hence not in the set of symbols understood
by backtrace.
Does anybody have an idea of the correct solution to this problem?
Marking the test xfail seems a bit drastic.
Thanks,
--
Will Newton
Toolchain Working Group, Linaro