标签: binutils

我在使用gcc 3.2.3与binutils 2.18链接共享库时遇到问题.当我尝试链接库时,我收到以下错误:

在.rodata节中引用的.gnu.linkonce.t _...:在丢弃的部分.gnu.linkonce.t中定义...

我已经做了相当多的谷歌搜索,大多数地方似乎表明这是一个回归引入binutils 2.17后来修复在2.18.50,但我很好奇,如果有人知道是否有任何特定的解决方案的问题没有不得不接触binutils和gcc.

谢谢.

我正在尝试用gcc反汇编为ARM构建的对象.不幸的是,objdump试图猜测代码是否是ARM和Thumb,并且错了:它认为我的代码是Thumb,而它实际上是ARM.

我看到objdump有一个选项可以强制它将所有指令解释为Thumb(-Mforce-thumb),但它没有强制ARM模式!

这对我来说似乎是一个非常奇怪的遗漏,它严重妨碍了我完成工作的能力(我在嵌入式设备上,我唯一的调试方法是查看反汇编).我尝试了各种方法,包括尝试告诉objdump使用不支持Thumb的ARM架构,但似乎没有任何工作.有任何想法吗？

(是的,我知道指令真的是 ARM ...)

解析动态重定位时符号查找的搜索顺序是什么？

解析共享库的符号时,加载器首先搜索"主可执行文件"(让主可执行文件覆盖定义......)或者什么？

我想知道GCC为每个编译单元集合生成了多少目标代码,但是我遇到了一个奇怪的问题,即来自binutils的"size"命令没有给出正确的结果.

我们来看一个只包含这个函数的C文件:

int foo (int a, int b)
{
  return a+b;
}

我们可以编译它并使用"size"和"objdump"检查目标代码大小:

$ gcc -O foo.c -c
$ size foo.o
   text    data     bss     dec     hex filename
     52       0       0      52      34 foo.o
$ objdump -d foo.o

foo.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <foo>:
   0:   8d 04 37                lea    (%rdi,%rsi,1),%eax
   3:   c3                      retq   

从objdump输出中可以清楚地看出,目标代码大小是4个字节.但是,大小报告52个字节,这是不正确的.

从使用"-D"选项到objdump,它看起来像异常处理代码,也许其他一些东西正在通过"大小"来衡量,并添加到我真正关心的代码的大小.有没有人知道一个相对简单的方法来获得大小忽略这些额外的东西？

我尝试从目标文件中删除符号，如下所示：

gcc -c test.c 

strip --strip-symbol=test_sym test.o test.o

test_sym是一个在 中实现的函数test.c。

strip返回以下消息：

strip: not stripping symbol 'test_sym' because it is named in a relocation.

由于该符号是在同一文件中实现的，因此会出现该错误。但是有没有办法删除该符号？

我在CentOS 7上使用Devtoolset-7并且已经构建了Boost 1.65.1 w/it.但是当我链接我的应用程序时,我有以下内容:

/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/ld: /opt/rh/devtoolset-7/root/usr/lib64/libboost_unit_test_framework.a(compiler_log_formatter.o)(.text._ZN5boost9unit_test5utils11string_castINS0_13basic_cstringIKcEEEESsRKT_[_ZN5boost9unit_test5utils11string_castINS0_13basic_cstringIKcEEEESsRKT_]+0x3c): unresolvable R_X86_64_NONE relocation against symbol `_ZTVSt9basic_iosIcSt11char_traitsIcEE@@GLIBCXX_3.4'
/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status

搜索更多信息R_X86_64_NONE并没有给出任何有价值的结果:大多数类似的问题没有任何答案或精确解释这是什么以及如何解决它.

所以我的问题是:

• 这个错误究竟意味着什么？
• 是什么R_X86_64_NONE和为什么"没有任何重新定位"(根据bintils来源)ELF标题中存在的符号类型？

附录:

• 链接单元测试可执行文件时出错,链接到我的静态库和Boosts的静态库(单元测试框架)
• 所有静态库(Boost和我的一个)都内置了-fPIC选项

PS.我真的希望这个问题能够一次又一次地解决(已经打过几次,但这次更新到最新的binutils并没有帮助).(将对此问题的任何活动开始赏金)

因此,我们正在学校学习MIPS架构,我们正在实施MIPS32架构.我以为我会使用GNU cross-binutils作为汇编程序但是在处理jal,j和jr指令时我得到了奇怪的输出.汇编程序似乎将指令插入错误的位置.我不知道为什么会发生这种情况,我怀疑MIPS汇编程序会破坏,所以我认为这应该发生.

这是我的虚拟程序集文件:

.section .text
.globl __start

__start:
   addi $a0, $0, 100
   addi $a1, $0, 200 
   jal test

test:
   add $v0, $a0, $a1
   jr $ra

但是,当我反汇编时,我得到这个输出:

Disassembly of section .text:

00000000 <__start>:
   0:   20040064    addi    a0,zero,100
   4:   0c000003    jal c <test>    <--- Why is jal coming before addi?
   8:   200500c8    addi    a1,zero,200

0000000c <test>:
   c:   03e00008    jr  ra  <--- Why is jr coming before add?
  10:   00851020    add v0,a0,a1
    ...

这是一些建筑怪癖吗？如果是这样,这背后的理由是什么？

编辑:测试添加一些nop只是为了...

.section .text
.globl __start

__start:
   addi $a0, $0, …

LLVM 编译器工具链有一个与普通 gcc 兼容的 gcc。使用 llvm-gcc 的优点是可以访问任意目标，这意味着当您尝试编译为随机架构时，正常的 gcc 会说没有这样的目标，比如 mips-apple-darwin。然而，llvm-gcc 实际上会在 mips 处理器上为 Mac OS X 构建一个编译器。

然而，这里有一个问题：要构建到随机目标，您需要已经为该目标构建的 binutils。因此，如果您有一个 llvm 可以编译到但 binutils 不能编译的目标，那么您就不能制作编译器，因为 GNU Binutils 不支持该目标。

所以......问题是：是否有类似 llvm-gcc 的等效 llvm-binutils 与 GNU Binutils 兼容？（意味着构建到任意目标的目标，而不是列表中的目标。）

编辑：

通过任意，我的意思是我在运行 llvm-gcc 时不选择目标，而是在编译 llvm-gcc 时选择目标。含义：如果我尝试为 mips-apple-darwin 编译 GCC，则会得到不支持的目标。但是如果我为 mips-apple-darwin 构建 llvm-gcc，只要我有 mips-apple-darwin-as 和 mips-apple-darwin-ld，它就可以工作。

在Linux上,我试图将静态链接的ELF文件剥离到基本要素.当我跑:

strip --strip-unneeded foo

要么

strip --strip-all foo

生成的文件仍然有一个胖的.notes部分,似乎充满了时髦的字符串.

是非常需要.notes部分,还是可以使用--remove-section安全地强制它？

谢谢你的帮助.

使用 GCC 编译大多数东西时，我收到此错误：

/..//bin/ld: cannot find crtbeginS.o: No such file or directory

crtbeginS.o 存在于 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/crtbeginS.o （从 GCC 主干安装，6.0.0-主干）

我将该目录添加到 ldconfig 并运行 ldconfig，但它没有选择任何其他目录。（我在想，因为它是 .o 而不是 .so）

作为临时修复，我尝试创建指向 /usr/local/lib64/crtbeginS.o 的符号链接 - 但这给出了相同的错误。

我该怎么办，所以总是查看 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/ 目录来查找库？

如果我运行gcc -print-search-dirs|grep "/usr/local/lib/gcc/x86_64-unknown-linux-gnu/6.0.0"，它会显示库：=/usr/local/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/:... 但是，这当然是 gcc 而不是 ld。

如果我运行ld --verbose | grep SEARCH_DIR，我会看到 /usr/local/lib/gcc_x86_64-unknown-linux-gnu/6.0.0 不包括在内。

我真的很想把它作为系统范围的默认值来做，所以我不必给所有的东西 -L。如果有必要，我可以从源代码构建 bintools。