我有一个简单的 JNI 函数,用于将文件中的数据读取到byte[]
C 代码中UnixUtil.unsafeReadToByteArray
,该代码实现为:
JNIEXPORT jlong JNICALL Java_net_xxxxxxx_UnixUtil_unsafeReadToByteArray
(JNIEnv *e, jclass jc, jint fd, jbyteArray array, jlong offset, jlong count){
signed char *array_native_ptr = (*e) -> GetByteArrayElements(e, array, NULL);
ssize_t bytes_read = read(fd, array_native_ptr + offset, (size_t) count);
(*e) -> ReleaseByteArrayElements(e, array, array_native_ptr, 0);
return bytes_read;
}
分析运行该函数的 Java 应用程序显示了一些不清楚的结果。这是顶部:
事实证明,最热门的事情之一0x18eb1f
是来自libc-2.27.so
. 我想了解它是什么,但 gdb 不知道它
(gdb) disas 0x18eb1f
No function contains specified address
Objdump'ing libc 来 grep 我发现的地址
18eb0b: 72 0f jb 18eb1c <__nss_group_lookup@GLIBC_2.2.5+0x24ddc>
[...]
18eb1c: 48 89 d1 mov %rdx,%rcx
18eb1f: f3 a4 rep movsb %ds:(%rsi),%es:(%rdi)
看起来它是__nss_group_lookup
while的一部分__nss_group_lookup
似乎不包含地址:
(gdb) disas __nss_group_lookup
Dump of assembler code for function __nss_passwd_lookup:
0x0000000000169d40 <+0>: mov rax,QWORD PTR [rip+0x281121] # 0x3eae68
0x0000000000169d47 <+7>: mov DWORD PTR fs:[rax],0x26
0x0000000000169d4e <+14>: mov eax,0xffffffff
0x0000000000169d53 <+19>: ret
End of assembler dump. making the things more unclear then it was before.
使事情变得比以前更不清楚。
问题:您能否给出任何提示以了解为什么属于的指令__nss_group_lookup
在调用jni_GetByteArrayElements
/ 时是最热的,jni_ReleaseByteArrayElements
以及它实际上是什么。
我的期望是因为jni_GetByteArrayElements
/jni_ReleaseByteArrayElements
将byte[]
通过memcpy
它从 Java 堆复制到 C 堆将是最热门的。
显然,您系统上的 libc 不包含调试符号(.symtab
共享库中没有任何部分)。因此 gdb 显示离 最接近的导出符号.dynsym
,这与实际最热的函数无关。
rep movsb
指令表明这个片段是memcpy
实现的一部分。
安装libc-dbg
包(或在 Linux 发行版中的调用方式)。
例如,在我的 Ubuntu 18.04 上,地址__nss_group_lookup+0x24ddc
确实指向memcpy
内部:
(gdb) disas __nss_group_lookup+0x24ddc
Dump of assembler code for function __memmove_avx_unaligned_erms:
0x00007ffffef7ead0 <+0>: mov %rdi,%rax
...
0x00007ffffef7eb1c <+76>: mov %rdx,%rcx
0x00007ffffef7eb1f <+79>: rep movsb %ds:(%rsi),%es:(%rdi)
0x00007ffffef7eb21 <+81>: retq
本文收集自互联网,转载请注明来源。
如有侵权,请联系[email protected] 删除。
我来说两句