我真的需要libgcc的？ [英] Do I really need libgcc?

问题描述

我在Mac OS X 10.6使用GCC 4.6.2过。我用-static-libgcc的选项时，我编的，否则我的二进制文件查找libgcc中的系统上，我没有结束GCC 4.2确保任何支持在OS X上也能正常工作，但为什么我甚至需要libgcc的？我读了它和GNU文档说它包含算术运算目标处理器不能直接执行的。我怎么知道这些操作？而他们为什么这么复杂，我需要包括这个库？为什么不能只是GCC的优化code，而不是直接不必诉诸这些库函数呢？我有点困惑。任何洞察到这将是AP preciated！

I've been using GCC 4.6.2 on Mac OS X 10.6. I use the -static-libgcc option when I compile, otherwise my binaries look for libgcc on the system and I'm not sure anything over GCC 4.2 is supported on OS X. This works fine, but why do I even need libgcc? I read up on it and the GNU docs say it contains "arithmetic operations that the target processor cannot perform directly." How do I know what these operations are? And why are they so complex that I need to include this library? Why can't GCC just optimize the code directly instead of having to resort to these library functions? I'm a little confused. Any insight into this would be appreciated!

推荐答案

是的，你确实需要它....可能。如果你不需要它，然后静态链接它是无害的。如果您使用 -t 链接跟踪选项（我认为）需要它，你可以告诉。

Yes, you do need it .... probably. If you don't need it then statically linking it is harmless. You can tell if you need it by using the -t link trace option (I think).

有，你不能在一个指令做各种事情（通常之类的64位运算的32位体系结构）。这些事情可以做，但如果他们使用的指令不平凡的号码，然后它在一个地方的空间效率更高，让他们所有。

There are various things that you cant do in one instruction (typically things like 64-bit operations on 32-bit architectures). These things can be done, but if they use a non-trivial number of instructions then it's more space-efficient to have them all in one place.

在禁止使用 -O0 （这实际上是默认反正），那么GCC pretty多少总是使用libgcc中的例程。优化

When you disable optimization using -O0 (that's actually the default anyway) then GCC pretty much always uses the libgcc routines.

当您启用的速度的优化则GCC可以选择直接将指令序列到code（如果它知道如何）。你可能会发现，它结束了使用没有libgcc的版本 - 它肯定会使用更少的libgcc调用

When you enable speed optimization then GCC may choose to insert the instruction sequence directly into the code (if it knows how). You may find that it ends up using none of the libgcc versions - it will certainly use fewer libgcc calls.

当您启用的尺寸的优化，那么GCC可能preFER函数调用，也可能不会 - 这取决于什么GCC的开发者认为是最好的速度/大小权衡每种情况。需要注意的是，即使你告诉它以优化的速度，编译器可以判断的部分的功能是不可能被使用，并优化那些规模 - 更是这样，如果你使用PGO

When you enable size optimizations then GCC may prefer the function call, or may not - it depends on what the GCC developers think is the best speed/size trade-off in each case. Note that even when you tell it to optimize for speed, the compiler may judge that some functions are unlikely to be used, and optimize those for size - even more so if you use PGO.

基本上，你可以用同样的方式把它看作的memcpy 或数学库函数：编译器将内联其判断是有益的，并调用库函数功能，否则。编译器可以内联的标准功能和libgcc的功能不看库定义，当然 - 它只是知道他们做什么

Basically, you can think of it in the same way as memcpy or the math-library functions: the compiler will inline functions it judges to be beneficial, and call library functions otherwise. The compiler can "inline" standard functions and libgcc function without looking at the library definition, of course - it just "knows" what they do.

是否使用静态或动态libgcc中是一个有趣的折衷。一方面，一个动态的（共享）库将使用较少的内存在您的整个系统，并且更可能进行高速缓存，等等。另一方面，静态libgcc中具有较低的调用开销。

Whether to use static or dynamic libgcc is an interesting trade-off. On the one hand, a dynamic (shared) library will use less memory across your whole system, and is more likely to be cached, etc. On the other hand, a static libgcc has a lower call overhead.

最重要的事情，虽然是兼容性。显然，libgcc的图书馆是present你的程序运行，但它也必须是一个兼容的版本的。您在一个Linux发行版具有稳定的GCC版本就好了，但除此之外，静态链接是安全的。

The most important thing though is compatibility. Obviously the libgcc library has to be present for your program to run, but it also has to be a compatible version. You're ok on a Linux distro with a stable GCC version, but otherwise static linking is safer.

我希望回答你的问题。

这篇关于我真的需要libgcc的？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！