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
|
mistranslation: 0.939
socket: 0.936
device: 0.936
instruction: 0.935
assembly: 0.932
other: 0.929
semantic: 0.928
graphic: 0.911
boot: 0.909
vnc: 0.895
network: 0.886
KVM: 0.855
armeb regression since qemu version 2.8
Hi,
I have noticed a regression when I upgraded from qemu-armeb 2.7 to 2.8, and the problem is still present with version 2.10.1.
I am using qemu for GCC validation, noticed problems with testcases involving atomics, I'm attaching here atomic-exchange-4.exe.
# with 2.7:
$ qemu-armeb -cpu any -R 0 -L $PWD -E LD_LIBRARY_PATH=$PWD/lib $PWD/atomic-exchange-4.exe
$ echo $?
0
# with 2.8, 2.10.1:
$ qemu-armeb -cpu any -R 0 -L $PWD -E LD_LIBRARY_PATH=$PWD/lib $PWD/atomic-exchange-4.exe
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted (core dumped)
$ echo $?
134
The source code is gcc/testsuite/gcc.dg/atomic-exchange-4.c
Running with -d in_asm shows a difference early in the startup code:
IN: _dl_sysdep_start
[...]
0x40a17790: 908ff103 addls pc, pc, r3, lsl #2
and then the next address is not the same with qemu 2.7 and 2.10.1
I hope you have enough data/information to reproduce and confirm/fix the problem.
Thanks
Hi Christophe -- RTH posted a patchset yesterday which should fix this:
https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg04809.html
Oh, wait, different bug. Sorry for the noise...
I rather suspect something is going wrong when the dynamic loader attempts to paw through the ELF auxiliary vector...
Ah, that's a false positive. We flipped the order we put entries in the AUXV in commit 7c4ee5bcc82e64, so the code divergence is just because now _dl_sysdep_start is processing the entries in the opposite order to what it used to. (The "addls pc, pc, r3, lsl #2" is jumping into the jump table for the switch on different AUXV entry tags.) The traces converge again at 0x40817830.
I think what's actually happening is that we're failing on one of the tests in main(). This would be much easier to diagnose if the test case code printed information about what it was doing and what the failed test case was...
Indeed I wish GCC tests printed information rather than just calling abort()...
I'll add some printfs and see what this says.
I added printfs after each 'count++' statement, and here is what I got:
qemu-2.7:
ATOMIC_RELAXED OK
ATOMIC_ACQUIRE OK
ATOMIC_RELEASE OK
ATOMIC_ACQ_REL OK
ATOMIC_SEQ_CST OK
ATOMIC_RELAXED OK
ATOMIC_ACQUIRE OK
ATOMIC_RELEASE OK
ATOMIC_ACQ_REL OK
ATOMIC_SEQ_CST OK
ALL TESTS PASSED
qemu-2.10.1:
ATOMIC_RELAXED OK
ATOMIC_ACQUIRE OK
ATOMIC_RELEASE OK
ATOMIC_ACQ_REL OK
ATOMIC_SEQ_CST OK
qemu: uncaught target signal 6 (Aborted) - core dumped
On 20 October 2017 at 16:12, Christophe Lyon
<email address hidden> wrote:
> I'll add some printfs and see what this says.
I had a dig further in the logs and I suspect that we're either
doing the two halves of strexd or the two halves of ldrexd wrong
for linux-user bigendian.
thanks
-- PMM
https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg00155.html should fix this bug.
Fix committed and will be in 2.11.0 rc0.
Great, thanks!
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=3448d47b3172015006b7
|