1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
|
other: 0.893
permissions: 0.888
performance: 0.872
socket: 0.872
semantic: 0.868
device: 0.867
PID: 0.844
graphic: 0.839
debug: 0.825
vnc: 0.804
boot: 0.796
KVM: 0.746
network: 0.736
files: 0.664
sh4: Unsupported syscall: 186
Hello!
I'm currently testing qemu as a possibility to set up a buildd for the Debian sh4 port.
I set up qemu and an sh4 chroot as described in the Debian Wiki [1]. This seems to be working mostly fine (besides the fact that qemu segfaults on an amd64 host while it runs fine on an i386 host, I'll file a separate bug report). However, when installing python3.4 in the sh4 chroot, qemu repeatedly printed an error message about an unimplemented syscall: 186:
qemu: Unsupported syscall: 186
From the source code in linux-user/sh4/syscall_nr.h it's apparent that 186 is defined as
#define TARGET_NR_sigaltstack 186
Looking at the implementation part, it becomes obvious that this syscall is not enabled for sh4:
#if defined(TARGET_I386) || defined(TARGET_ARM) || defined(TARGET_MIPS) || \
defined(TARGET_SPARC) || defined(TARGET_PPC) || defined(TARGET_ALPHA) || \
defined(TARGET_M68K) || defined(TARGET_S390X) || defined(TARGET_OPENRISC)
ret = do_sigaltstack(arg1, arg2, get_sp_from_cpustate((CPUArchState *)cpu_env));
break;
#else
goto unimplemented;
#endif
Is there any particular reason why TARGET_NR_sigaltstack is not enabled on sh4? If not, could you enable it?
Thanks,
Adrian
> [1] https://wiki.debian.org/QemuUserEmulation
I have enabled this syscall in the source code now and performing a test build and run and will report back.
Furthermore, looking at the kernel sources, both the 32-bit and 64-bit Linux SH-specific code defines "sigaltstack" as syscall 186:
> https://github.com/torvalds/linux/blob/master/arch/sh/kernel/syscalls_32.S#L205
> https://github.com/torvalds/linux/blob/master/arch/sh/kernel/syscalls_64.S#L209
The whole syscall also doesn't appear to be architecture-specific after reading the manpage for sigaltstack. Is it?
Will report back after further testing.
Thanks,
Adrian
Hello!
The attached patch enables the sigaltstack syscall in qemu-sh4.
The following minimal test code verifies that sigaltstack works as expected:
=============================================================
#include <setjmp.h>
#include <signal.h>
#include <stdlib.h>
#include <stdio.h>
jmp_buf exit_jmp;
void handler(int x)
{
longjmp(exit_jmp, 1);
}
int f(void)
{
return f();
}
int main(void)
{
stack_t sigstack;
sigstack.ss_sp = malloc(1024*1024);
sigstack.ss_size = 1024*1024;
sigstack.ss_flags = 0;
sigaltstack(&sigstack, NULL);
struct sigaction sa;
sa.sa_handler = handler;
sigemptyset(&sa.sa_mask);
sa.sa_flags = SA_ONSTACK;
sigaction(SIGSEGV, &sa, NULL);
if (setjmp(exit_jmp) == 0)
{
return f();
}
puts("recovered");
return 0;
}
=============================================================
Without sigaltstack enabled, this code produces a segmentation fault. With sigaltstack enabled, it prints out "recovered".
Also posted on qemu-devel mailing list:
> http://lists.nongnu.org/archive/html/qemu-devel/2015-11/msg04300.html
> http://lists.nongnu.org/archive/html/qemu-devel/2015-11/msg04301.html
Cheers,
Adrian
Ping. Any chance to get this merged?
I don't think this patch could have any particular bad impact on qemu as it affects the sh4 emulation only and so far my tests with building packages on qemu-sh4 have shown no regressions. But with the patch, sigaltstack now works fine on sh4 which the above testcase also positively has proven.
Having this bug and #1254824 fixed would help the sh4 porters in Debian quite a lot as qemu-sh4 can be used to set up a virtual buildd for this architecture.
Adrian
> [1] https://bugs.launchpad.net/ubuntu/+source/qemu-linaro/+bug/1254824
Looks like we fixed this in commit c0d35736323e5b in December, which was released as part of QEMU 2.6.
|