|
From: Anil S. <ani...@li...> - 2014-02-17 11:55:37
|
Hi Julian,
Thanks for your response. I did objdump on "/lib/ld-2.18-2013.10.so", and
the instruction seems to be the "*mrs x3, dczid_el0*" (status reg
inst.), . The offset is 0x16284 (the unhandled instruction is reported at
0x4016284).
Thanks and Regards,
Anil
. . .
1622c: a9021d07 stp x7, x7,
[x8,#32]
stp A_l, A_l, [dst,
#48]
16230: a9031d07 stp x7, x7,
[x8,#48]
stp A_l, A_l, [dst,
#64]!
16234: a9841d07 stp x7, x7,
[x8,#64]!
subs count, count,
#64
16238: f1010042 subs x2, x2,
#0x40
b.ge
1b
1623c: 54ffff6a b.ge 16228
<_dl_var_init+0x26c8>
tst count,
#0x3f
16240: f240145f tst x2,
#0x3f
add dst, dst,
#16
16244: 91004108 add x8, x8,
#0x10
b.ne
L(tail63)
16248: 54fffb01 b.ne 161a8
<_dl_var_init+0x2648>
RET
1624c: d65f03c0
ret
#ifndef
DONT_USE_DC
/* For zeroing memory, check to see if we can use the ZVA feature
to
* zero entire 'cache' lines.
*/
L(zero_mem):
mov A_l, #0
16250: d2800007 mov x7, #0x0 //
#0
cmp count,
#63
16254: f100fc5f cmp x2,
#0x3f
b.le
L(tail_maybe_tiny)
16258: 54fffa4d b.le 161a0
<_dl_var_init+0x2640>
neg tmp2,
dst
1625c: cb0803e4 neg x4,
x8
ands tmp2, tmp2,
#15
16260: f2400c84 ands x4, x4,
#0xf
b.eq
1f
16264: 540000c0 b.eq 1627c
<_dl_var_init+0x271c>
sub count, count,
tmp2
16268: cb040042 sub x2, x2,
x4
stp A_l, A_l,
[dst]
1626c: a9001d07 stp x7, x7,
[x8]
add dst, dst,
tmp2
16270: 8b040108 add x8, x8,
x4
cmp count,
#63
16274: f100fc5f cmp x2,
#0x3f
b.le
L(tail63)
16278: 54fff98d b.le 161a8
<_dl_var_init+0x2648>
1:
/* For zeroing small amounts of memory, it's not worth setting up
* the line-clear code.
*/
cmp count,
#128
1627c: f102005f cmp x2,
#0x80
b.lt
L(not_short)
16280: 54fffc0b b.lt 16200
<_dl_var_init+0x26a0>
mov tmp3w,
#4
and zva_len, tmp1w, #15 /* Safety: other bits reserved.
*/
lsl zva_len, tmp3w,
zva_len
str zva_len, [tmp2,
#:lo12:L(cache_clear)]
#else
mrs tmp1,
dczid_el0
* 16284: d53b00e3 mrs x3, dczid_el0 *
tbnz tmp1, #4,
L(not_short)
16288: 3727fbc3 tbnz w3, #4, 16200
<_dl_var_init+0x26a0>
mov tmp3w,
#4
1628c: 52800089 mov w9, #0x4 //
#4
and zva_len, tmp1w, #15 /* Safety: other bits reserved.
*/
16290: 12000c65 and w5, w3, #0xf
lsl zva_len, tmp3w,
zva_len
16294: 1ac52125 lsl w5, w9,
w5
#endif
. . .
On 17 February 2014 16:50, Julian Seward <js...@ac...> wrote:
>
> Anil,
>
> Support for aarch64 is under active development. V can run large
> amounts of integer and FP code -- basically anything that
> gcc-4.8.2 -O2 generates -- and SIMD support is in progress.
>
> I suspect you have run across an unsupported SIMD instruction in
> handwritten assembly code for memset:
>
> > ==1747== valgrind: Unrecognised instruction at address 0x4016284.
> > ==1747== at 0x4016284: memset (memset.S:175)
>
> Can you use objdump to find the instruction? Try running with the flags
> -v --sym-offsets=yes -- you can maybe deduce from that output in which
> shared object the instruction is (ld.so or glibc.so) and where it is
> relative to the start of the function.
>
> J
>
>
|