为什么nm报告由C编写并嵌入在golang对象中的库的变量符号错误的偏移值太大?

我有一个包含以下变量的库:

const static volatile int64_t  head1   = 0xffffffffffffffff;
const static volatile int64_t  head2   = 0xffffffffffffffff;
const static volatile int64_t  seed = 1;
const static volatile int64_t  tail1   = 0xffffffffffffffff;
const static volatile int64_t  tail2   = 0xffffffffffffffff;

我已经将它编译为libnantoka.a的库文件。然后通过cgo链接到go模块中,如下所示:

/*
#cgo LDflaGS: -L. -lssl -lcrypto -lpthread -ldl -lm -lnantoka
#include <nantoka.h>
#include <stdbool.h>
*/
import "C"

然后,go build -o main main.go

创建的可执行文件 main

我通过二进制模式匹配找到了种子的偏移地址,如下所示:

od -A x -x main | grep "0001 0000 0000 0000"
0d61f0 ffff ffff ffff ffff 0001 0000 0000 0000

看来,符号种子的偏移地址可能是 0xd61f8 。另外,我确保如下操作:

od -A x -x -j 0xd61e0 main | head -n4
0d61e0 7472 000a 0000 0000 ffff ffff ffff ffff
0d61f0 ffff ffff ffff ffff 0001 0000 0000 0000
0d6200 ffff ffff ffff ffff ffff ffff ffff ffff
0d6210 3130 3332 3534 3736 3938 3130 3332 3534

它表示0xd61f8必须是值为1的64位int,在所有“ f”的128位之间。我确定符号种子的偏移地址必须为 0xd61f8

但是,nm的结果令人惊讶地是:

nm main | grep seed
000e61f8 r seed

结果 e61f8 必须是.rodata段开头的偏移地址,但大于文件顶部的实际偏移地址!

我很困惑,为什么nm报告如此大的错误偏移量?我非常感谢您的任何建议!谢谢。

顺便说一下,环境是Raspberry Pi模型B,go版本是1.13.5,如下所示:

uname -a
Linux raspberrypi 4.19.50+ #896 Thu Jun 20 16:09:52 BST 2019 armv6l GNU/Linux

go version
go version go1.13.5 linux/arm

主要部分的信息如下:

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .interp       00000019  00010174  00010174  00000174  2**0
                  CONTENTS,ALLOC,LOAD,READONLY,DATA
  1 .note.ABI-tag 00000020  00010190  00010190  00000190  2**2
                  CONTENTS,DATA
  2 .note.go.buildid 00000064  000101b0  000101b0  000001b0  2**2
                  CONTENTS,DATA
  3 .note.gnu.build-id 00000024  00010214  00010214  00000214  2**2
                  CONTENTS,DATA
  4 .gnu.hash     00000568  00010238  00010238  00000238  2**2
                  CONTENTS,DATA
  5 .dynsym       00000b70  000107a0  000107a0  000007a0  2**2
                  CONTENTS,DATA
  6 .dynstr       00000974  00011310  00011310  00001310  2**0
                  CONTENTS,DATA
  7 .gnu.version  0000016e  00011c84  00011c84  00001c84  2**1
                  CONTENTS,DATA
  8 .gnu.version_r 000000a0  00011df4  00011df4  00001df4  2**2
                  CONTENTS,DATA
  9 .rel.dyn      00000020  00011e94  00011e94  00001e94  2**2
                  CONTENTS,DATA
 10 .rel.plt      00000368  00011eb4  00011eb4  00001eb4  2**2
                  CONTENTS,DATA
 11 .init         0000000c  0001221c  0001221c  0000221c  2**2
                  CONTENTS,CODE
 12 .plt          00000530  00012228  00012228  00002228  2**2
                  CONTENTS,CODE
 13 .text         00094338  00012758  00012758  00002758  2**3
                  CONTENTS,CODE
 14 .fini         00000008  000a6a90  000a6a90  00096a90  2**2
                  CONTENTS,CODE
 15 .rodata       0004001c  000a6a98  000a6a98  00096a98  2**3
                  CONTENTS,DATA
 16 .typelink     00000cfc  000e6ab8  000e6ab8  000d6ab8  2**3
                  CONTENTS,DATA
 17 .itablink     0000002c  000e77b4  000e77b4  000d77b4  2**2
                  CONTENTS,DATA
 18 .gopclntab    0005fd79  000e77e0  000e77e0  000d77e0  2**3
                  CONTENTS,DATA
 19 .ARM.exidx    00000008  0014755c  0014755c  0013755c  2**2
                  CONTENTS,DATA
 20 .eh_frame     00000004  00147564  00147564  00137564  2**2
                  CONTENTS,DATA
 21 .tbss         00000008  00157ee8  00157ee8  00137ee8  2**2
                  ALLOC,THREAD_LOCAL
iCMS 回答:为什么nm报告由C编写并嵌入在golang对象中的库的变量符号错误的偏移值太大?

暂时没有好的解决方案,如果你有好的解决方案,请发邮件至:iooj@foxmail.com
本文链接:https://www.f2er.com/1613097.html

大家都在问