我正在尝试构建 Gnu binutils，通过定义宏SYSV386_COMPAT 0来改变它生成一些 FPU 操作码的方式，从而解锁行为。
我可以轻松地进入头文件并手动设置值，但是如何调用配置脚本才能#define SYSV386_COMPAT 0在命令行上指定等效项？如果可能的话，我更愿意在命令行上指定一些内容（只是因为该功能是可传递的，而且我认为我不应该破解源代码）。话虽如此，我已经尝试阅读至少一些 FM，但未能在或AC_DEFINE(SYSV386_COMPAT, 0)中插入。binutils/configure.ingas/configure.in
我正在尝试按照我在此处找到的说明安装交叉编译器.我使用的是64位版本的Ubuntu 13.10.一旦我输入配置binutils的命令,我得到:
Configuring for a x86_64-unknown-linux-gnu host.
Invalid configuration `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized
Invalid configuration `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized
Unrecognized host system name x86_64-unknown-linux-gnu.
是否真的有64位版本的binutils？如果没有,任何人都可以告诉我要输入什么命令以避免此错误？
尝试使用类似命令在我的计算机上安装任何软件包时
cabal install http-conduit
安装中止,出现以下错误:
/usr/bin/ld: --hash-size=31: unknown option
我该如何解决这个问题？
注意:这个问题故意不会显示研究工作,因为它是以问答方式立即回答的.
我刚刚阅读了这篇出色的文章：http : //neugierig.org/software/chromium/notes/2011/08/static-initializers.html 然后我尝试了：https : //gcc.gnu.org/onlinedocs/gccint/Initialization .html
不过，它关于查找初始化程序的内容对我不起作用。该.ctors部分不可用，但我可以找到.init_array（另请参阅Can't find .dtors and .ctors in binary）。但是我如何解释输出？我的意思是，总结页面的大小也可以由size命令及其.bss列处理 - 或者我错过了什么？
此外，nm不报告任何*_GLOBAL__I_*符号，仅报告*_GLOBAL__N_*函数和 - 更有趣的 -_GLOBAL__sub_I_somefile.cpp条目。后者可能表示具有全局初始化的文件。但是我能以某种方式获得正在运行的构造函数列表吗？理想情况下，一个工具会给我一个列表
Foo::Foo in file1.cpp:12
Bar::Bar in file2.cpp:45
...
（假设我有可用的调试符号）。有这样的工具吗？如果不是，那怎么写呢？该.init_array部分是否包含指向可以通过一些 DWARF 魔法转换为上述代码的指针？
我将binutils-2.25.1安装到/usr/local/binutils-2.25.1,配置了
../configure --prefix=/usr/local/binutils-2.25.1 --enable-plugins --enable-gold --disable-werror
我想构建RPM包 - 使用LTO支持的gcc,它使用来自/usr/local/binutils-2.25.1的链接器ld.
我尝试:
Summary: The GNU Compiler Collection
Name: gcc-custom
Version: 4.9.3
%define full_name gcc-%{version}
%define binutils_path /usr/local/binutils-2.25.1
Release: 0
...
Requires(post): /sbin/ldconfig
Requires(postun): /sbin/ldconfig
%description
%prep
%setup -q -a0 -n %{full_name}
%build
AR=%{binutils_path}/bin/ar NM=%{binutils_path}/bin/nm RANLIB=@%{binutils_path}/bin/ranlib ./configure \
--prefix=/usr/local/%{full_name} \
--disable-multilib \
--enable-languages=c,c++ \
--enable-lto \
--enable-linker-build-id \
--enable-plugin \
--with-ld=%{binutils_path}/bin/ld \
--with-plugin-ld=%{binutils_path}/bin/ld \
--with-as=%{binutils_path}/bin/as
make
%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT
%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig
%clean …我有一个简单的测试程序调用pthread_cond_broadcast.
与ld链接器链接时,显示:
情况1:
$ nm ld-test | grep cond_broadcast
U pthread_cond_broadcast@@GLIBC_2.3.2
与gold链接器链接时,它显示:
案例2:
$ nm gold-test | grep cond_broadcast
U pthread_cond_broadcast
pthread/libc包含几个带有不同版本符号的pthread_cond_broadcast符号,可能是因为ABI已被更改.
$ nm /lib64/libc.so.6 |grep cond_broadca
00000036b84f7d30 t __pthread_cond_broadcast
00000036b85278f0 t __pthread_cond_broadcast_2_0
00000036b84f7d30 T pthread_cond_broadcast@@GLIBC_2.3.2
00000036b85278f0 T pthread_cond_broadcast@GLIBC_2.2.5
$ nm /lib64/libpthread.so.0 |grep cond_broadcast
00000036b880bee0 t __pthread_cond_broadcast
00000036b880c250 t __pthread_cond_broadcast_2_0
00000036b880bee0 T pthread_cond_broadcast@@GLIBC_2.3.2
00000036b880c250 T pthread_cond_broadcast@GLIBC_2.2.5
所以问题是:
gold和老/正常之间的行为不同ld.pthread_cond_broadcast符号时,在案例2中正在运行时使用哪个pthread_cond_broadcast 符号.pthread_cond_broadcast的最新实现？最老的 ？这是使用gcc 4.9.2和binutils 2.24中的gold/ld链接器(作为Red Hat 的devtoolset-3的一部分.)
我有一些使用GCC构建的固件,它运行在基于ARM Cortex M0的微控制器上.构建当前生成单个二进制映像,可以将其写入微控制器的程序存储器中.
由于与字段更新有关的原因,我需要将此图像分成两个部分,可以单独更新.我将这些称为Core和App.
核心:包含中断向量表,main()例程以及各种驱动程序和库例程.它将位于程序存储器的前半部分.
应用:包含特定于应用程序的代码.它将位于程序存储器的后半部分.它将在一个已知地址处有一个入口点,由核心调用以启动应用程序.它将通过已知地址访问核心中的功能和数据.
这里有一些明显的限制,我很清楚:
构建应用程序时,需要知道核心中符号的地址.因此必须首先构建核心,并且在链接应用程序时必须可用.
应用程序映像仅与其构建的特定核心映像兼容.
可以在不更新核心的情况下更新应用程序,但反之亦然.
所有这一切都没问题.
我的问题很简单,我如何使用GCC和GNU binutils构建这些图像？
基本上我想像正常的固件映像一样构建核心,然后构建应用程序映像,应用程序将核心视为库.但是,共享链接(这将需要动态链接机制)或静态链接(将复制用于应用程序二进制文件的核心功能)都不适用于此处.我正在尝试做的事情实际上要简单得多:使用已知的固定地址链接现有的二进制文件.我不清楚如何用这些工具做到这一点.
我有一个由某人编译的 binutils 版本。我需要使用相同的选项重新编译一个新的 binutils。
我知道这会gcc -v打印出配置选项。那么也许有什么方法可以读取binutils?
musl C 库只有符号版本控制的近似实现。这可能导致具有不同符号版本的符号绑定在一起，这在完整实现中不会发生。因此，希望使用 musl 构建的项目最好完全避免符号版本控制。（不支持符号版本控制本身对于工具链来说不一定是一个糟糕的选择；这完全取决于目标受众。）
但是，Alpine Linux 工具链编译 binutils 时具有完整的符号版本支持：GAS 支持该.symver指令，链接编辑器处理版本脚本并分配符号版本（就像在 GNU/Linux 上一样）。一个简单的编译器/汇编器或链接检查显示符号版本的支持。因此，Alpine Linux 在发行版中包含的一些共享对象实际上使用了符号版本控制，尽管 musl 动态加载器会忽略这些数据。（数据只会使二进制文件膨胀。）
在某些情况下，软件无法运行（在构建正常之后），因为它以 musl 动态链接器不支持的方式使用兼容性符号（没有默认版本的符号）。这是一个不起作用的小例子：
cat > symver.c <<EOF
void
compat_function (void)
{
}
__asm__ (".symver compat_function,compat_function@SYMVER");
void
call_compat_function (void)
{
return compat_function ();
}
EOF
echo "SYMVER { };" > symver.map
cat > main.c <<EOF
extern void call_compat_function (void);
int
main (void)
{
call_compat_function ();
}
EOF
gcc -fpic -shared -o symver.so -Wl,--version-script=symver.map symver.c
gcc -Wl,--rpath=. -o main …