反汇编的 gcc 输出似乎执行了“call 0”操作而不是“调用函数偏移”，但工作正常
我刚刚查看了从这个 C 程序中获得的一个非常简单的 SPARC 汇编输出：
int addition_func(int a, int b)
{
return(a+b);
}
void main()
{
int a = 20;
int b = 19;
int res;
res = addition_func(a, b);
}
.text 节的反汇编：
00000000 <addition_func>:
0: 81 c3 e0 08 retl
4: 90 02 00 09 add %o0, %o1, %o0
00000008 <main>:
8: 90 10 20 14 mov 0x14, %o0
c: 92 10 20 13 mov 0x13, %o1
10: 82 13 c0 00 mov %o7, %g1
14: 40 00 00 00 call 14 <main+0xc>
18: 9e 10 40 00 mov %g1, %o7
1c: 01 00 00 00 nop
我不明白为什么“call”指令说：
call 14 <main+0xc>
为什么不是：
call 0 <addition_func+0x0>
程序运行良好，但是，这个输出没有多大意义 大部头书。有什么建议为什么要这样处理吗？
谢谢
I had just a look at a very simple SPARC assembly output that I got from this C programm:
int addition_func(int a, int b)
{
return(a+b);
}
void main()
{
int a = 20;
int b = 19;
int res;
res = addition_func(a, b);
}
Disassembly of section .text:
00000000 <addition_func>:
0: 81 c3 e0 08 retl
4: 90 02 00 09 add %o0, %o1, %o0
00000008 <main>:
8: 90 10 20 14 mov 0x14, %o0
c: 92 10 20 13 mov 0x13, %o1
10: 82 13 c0 00 mov %o7, %g1
14: 40 00 00 00 call 14 <main+0xc>
18: 9e 10 40 00 mov %g1, %o7
1c: 01 00 00 00 nop
I do not understand why the "call" instruction says:
call 14 <main+0xc>
Why is it not:
call 0 <addition_func+0x0>
The program works fine, however, this output does not make too much sense
to me. Any suggestions why it is handled this way?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我假设您使用的是 GCC，但其他编译器/汇编器应该有等效的选项。
这不是汇编输出；而是汇编输出。这是拆解。如果您想要将输入输入到汇编器，请使用
gcc -S。值得注意的数字不是 14 — 该指令是对 0 的相对地址的调用：
如果您要反汇编使用
-ffunction-sections编译的目标文件，则指令只是一个由链接器修复的占位符。链接器将用addition_func的实际偏移量填充它；如果转储重定位表，您可能会看到这一点。I'll assume you're using GCC, but other compilers/assemblers should have equivalent options.
That's not the assembly output; it's the disassembly. If you want the input to the assembler, use
gcc -S.The notable number is not 14 — the instruction is a call to a relative address of 0:
If you're disassembling an object file compiled with
-ffunction-sections, then the instruction is simply a placeholder to be fixed up by the linker. The linker will fill it in with the actual offset toaddition_func; you might see this if you dump the relocation tables.长话短说，它是目标文件中未填充的相对调用，等待链接器填充到实际符号的适当偏移量。在那之前，相对偏移量为 0，如 x86，这意味着它是 相对调用自身（恰好是代码段内的绝对地址0x14，距main的偏移量为0xc）。 SPARC 相对调用似乎是相对于当前指令的开始，而不是像 x86 那样相对于结束。
Long story short, it's an unfilled-in relative call in an object file waiting to be filled in with the appropriate offset by the linker to the actual symbol. Until that time the relative offset is 0, like x86, meaning it's relatively calling itself (which happens to be absolute address 0x14 within the code segment, which is an offset of 0xc from main). SPARC relative call appears to be relative to the start of the current instruction and not the end like x86.