blocks|key|2667744|text|位置独立代码意味着生成的机器代码不依赖于位于特定地址才能工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2667745|跳转将以相对而非绝对的形式产生。|2667746|伪装配：|2667747|PIC:无论代码是在地址100还是1000，这都可以工作。|2667748|100:+COMPARE+REG1,+REG2
101:+JUMP_IF_EQUAL+CURRENT%2B10
...
111:+NOP|code-block|syntax|javascript|2667749|非PIC:只有当代码位于地址100时才能工作。|2667750|100:+COMPARE+REG1,+REG2
101:+JUMP_IF_EQUAL+111
...
111:+NOP|2667751|编辑:回应评论。|2667752|如果您的代码是用-fPIC编译的，那么它适合包含在库中--库必须能够从内存中的首选位置重新定位到另一个地址，在您的库喜欢的地址上可能有另一个已经加载的库。|2667753|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Y|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Z|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|10|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|11|8|@]|9|@]|A|$]]|$1|O|3|P|5|J|7|12|8|@]|9|@]|A|$K|L]]|$1|Q|3|R|5|6|7|13|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|14|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|V|$]]

Position Independent Code means that the generated machine code is not dependent on being located at a specific address in order to work.

E.g. jumps would be generated as relative rather than absolute.

Pseudo-assembly:

PIC: This would work whether the code was at address 100 or 1000

<pre><code>100: COMPARE REG1, REG2
101: JUMP_IF_EQUAL CURRENT+10
...
111: NOP
</code></pre>

Non-PIC: This will only work if the code is at address 100

<pre><code>100: COMPARE REG1, REG2
101: JUMP_IF_EQUAL 111
...
111: NOP
</code></pre>

EDIT: In response to comment.

If your code is compiled with -fPIC, it's suitable for inclusion in a library - the library must be able to be relocated from its preferred location in memory to another address, there could be another already loaded library at the address your library prefers.

blocks|key|2308838|text|我将尝试用一种简单的方式解释已经说过的话。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2308839|每当加载共享库时，加载程序(加载您运行的任何程序的OS上的代码)将根据对象加载到的位置更改代码中的某些地址。|2308840|在上面的例子中，非PIC代码中的"111“是由加载器在第一次加载时编写的。|2308841|对于非共享对象，您可能希望它是这样的，因为编译器可以对该代码进行一些优化。|2308842|对于共享对象，如果另一个进程想要“链接”到该代码，它必须将其读取到相同的虚拟地址，否则"111“就没有意义了。但这个虚拟空间可能已经在第二个过程中使用了。|2308843|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

I'll try to explain what has already been said in a simpler way.
Whenever a shared lib is loaded, the loader (the code on the OS which load any program you run) changes some addresses in the code depending on where the object was loaded to.
In the above example, the &quot;111&quot; in the non-PIC code is written by the loader the first time it was loaded.
For not shared objects, you may want it to be like that because the compiler can make some optimizations on that code.
For shared object, if another process will want to &quot;link&quot; to that code it must read it to the same virtual addresses or the &quot;111&quot; will make no sense. But that virtual-space may already be in use in the second process.

blocks|key|2667787|text|构建在共享库中的代码通常应该是与位置无关的代码，这样共享库就可以轻松地加载到(或多或少)内存中的任何地址。-fPIC选项确保GCC生成这样的代码。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2667788|entityMap^0|1H|5|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

Code that is built into shared libraries should normally be position-independent code, so that the shared library can readily be loaded at (more or less) any address in memory. The <code>-fPIC</code> option ensures that GCC produces such code.

blocks|key|2308886|text|再加上..。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2308887|每个进程都有相同的虚拟地址空间(如果使用linux中的标志来停止虚拟地址的随机化)(有关更多细节，仅为自己禁用和重新启用地址空间布局随机化。)|offset|length|2308888|因此，如果它的一个没有共享链接的exe+(假设的场景)，那么我们总是可以给予相同的虚拟地址给相同的asm指令，而不会有任何伤害。|2308889|但是，当我们想要将共享对象链接到exe时，我们不确定分配给共享对象的起始地址，因为它将取决于共享对象被linked.That的顺序，.so中的asm指令总是有不同的虚拟地址，这取决于它链接到的进程。|2308890|因此，一个进程可以在其自己的虚拟空间中将.so的起始地址指定为0x45678910，而其他进程可以同时给出0x12131415的起始地址，如果它们不使用相对寻址，.so将根本无法工作。|2308891|因此，他们总是必须使用相对寻址模式，因此fpic选项。|2308892|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/11238457/disable-and-re-enable-address-space-layout-randomization-only-for-mysef^0|0|1D|L|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|F|3|G|5|6|7|10|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|11|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|12|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|13|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]]]

Adding further...

Every process has same virtual address space (If randomization of virtual address is stopped by using a flag in linux OS)
(For more details <a href="https://stackoverflow.com/questions/11238457/disable-and-re-enable-address-space-layout-randomization-only-for-mysef">Disable and re-enable address space layout randomization only for myself</a>)

So if its one exe with no shared linking (Hypothetical scenario), then we can always give same virtual address to same asm instruction without any harm.

But when we want to link shared object to the exe, then we are not sure of the start address assigned to shared object as it will depend upon the order the shared objects were linked.That being said, asm instruction inside .so will always have different virtual address depending upon the process its linking to. 

So one process can give start address to .so as 0x45678910 in its own virtual space and other process at the same time can give start address of 0x12131415 and if they do not use relative addressing, .so will not work at all.

So they always have to use the relative addressing mode and hence fpic option.

blocks|key|2667964|text|在加载库或在运行时解析到动态库中函数的链接。因此，当程序运行时，可执行文件和动态库都被加载到内存中。无法预先确定加载动态库的内存地址，因为固定地址可能与需要相同地址的另一个动态库发生冲突。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2667965|有两种常用的方法来处理这个问题：|2667966|1.搬迁。如果有必要，将修改代码中的所有指针和地址，以适应实际的加载地址。重新定位由链接器和加载程序完成。|2667967|2.位置无关代码。代码中的所有地址都相对于当前位置。类Unix系统中的共享对象默认使用与位置无关的代码。如果程序运行很长时间，特别是在32位模式下，这比重新定位效率更低。|2667968|“位置独立代码”的名称实际上意味着：|offset|length|style|BOLD|2667969|“代码”部分不包含需要重新定位的绝对地址，但只包含自相关地址。因此，代码部分可以加载到任意内存地址，并在多个进程之间共享。|unordered-list-item|2667970|数据部分不能在多个进程之间共享，因为它通常包含可写数据。因此，数据部分可能包含需要重新定位的指针或地址。|2667971|所有公共函数和公共数据都可以在Linux中重写。如果主可执行文件中的函数与共享对象中的函数具有相同的名称，则main中的版本将优先处理，不仅在从main调用时，而且从共享对象调用时也是如此。同样，当main中的全局变量与共享对象中的全局变量具有相同的名称时，则会使用main中的实例，即使从共享对象访问时也是如此。这种所谓的符号插入是为了模仿静态库的行为.|2667972|共享对象有一个指向其函数的指针表(称为过程链接表(PLT)+)和一个指向其变量的指针表(称为全局偏移表(GOT)+)，以实现这一“覆盖”功能。|2667973|对函数和公共变量的所有访问都要经过这些表。|2667974|附注：在无法避免动态链接的情况下，有多种方法可以避免位置无关代码的耗时特性。|2667975|您可以从本文中了解更多内容：cpp.pdf|2667976|entityMap|0|LINK|mutability|MUTABLE|url|http://www.agner.org/optimize/optimizing_cpp.pdf^0|0|0|0|0|1|6|0|0|0|0|0|0|0|E|7|0|0^^$0|@$1|2|3|4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1B|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1C|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1D|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1E|8|@$J|1F|K|1G|L|M]]|9|@]|A|$]]|$1|N|3|O|5|P|7|1H|8|@]|9|@]|A|$]]|$1|Q|3|R|5|P|7|1I|8|@]|9|@]|A|$]]|$1|S|3|T|5|P|7|1J|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1K|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1L|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1M|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|1N|8|@]|9|@$J|1O|K|1P|1|1Q]]|A|$]]|$1|12|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]]|13|$14|$5|15|16|17|A|$18|19]]]]

The link to a function in a dynamic library is resolved when the library is loaded or at run time. Therefore, both the executable file and dynamic library are loaded into memory when the program is run.
The memory address at which a dynamic library is loaded cannot be determined in
advance, because a fixed address might clash with another dynamic library requiring the same address.
<hr />
There are two commonly used methods for dealing with this problem:
1.Relocation. All pointers and addresses in the code are modified, if necessary, to fit the actual load address. Relocation is done by the linker and the loader.
2.Position-independent code. All addresses in the code are relative to the current position. Shared objects in Unix-like systems use position-independent code by default. This is less efficient than relocation if program run for a long time, especially in 32-bit mode.
<hr />
The name &quot;position-independent code&quot; actually implies the following:
<ul>
<li>The code section contains no absolute addresses that need relocation, but only self relative
addresses. Therefore, the code section can be loaded at an arbitrary memory address and shared between multiple processes.
</li>
<li>The data section is not shared between multiple processes because it often contains
writeable data. Therefore, the data section may contain pointers or addresses that
need relocation.
</li>
<li>All public functions and public data can be overridden in Linux. If a function
in the main executable has the same name as a function in a shared object, then the
the version in main will take precedence, not only when called from main, but also when
called from the shared object. Likewise, when a global variable in the main has the same
name as a global variable in the shared object, then the instance in main will be
used, even when accessed from the shared object. This so-called symbol interposition is intended to mimic the behavior of static libraries.
</li>
</ul>
<hr />
A shared object has a table of pointers to its functions, called procedure linkage table (PLT), and a table
of pointers to its variables called global offset table (GOT) in order to implement this &quot;override&quot; feature.
All accesses to functions and public variables go through these tables.
p.s. Where dynamic linking cannot be avoided, there are various ways to avoid the time-consuming features of the position-independent code.
You can read more from this article: <a href="http://www.agner.org/optimize/optimizing_cpp.pdf" rel="noreferrer">http://www.agner.org/optimize/optimizing_cpp.pdf</a>

blocks|key|2308909|text|除了已经发布的答案之外，还有一个小的补充:未编译为独立于位置的对象文件是可重定位的；它们包含重定位表条目。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2308910|这些条目允许加载程序(将程序加载到内存中的代码)重写绝对地址，以调整虚拟地址空间中的实际加载地址。|2308911|操作系统将尝试与链接到同一共享对象库的所有程序共享加载到内存中的“共享对象库”的单个副本。|2308912|由于代码地址空间(与数据空间的部分不同)不一定是连续的，而且由于链接到特定库的大多数程序都有一个相当固定的库依赖树，所以这在大多数情况下都是成功的。在那些不一致的情况下，是的，在内存中可能需要有两个或多个共享对象库的副本。|2308913|显然，在程序和/或程序实例之间随机设置库的加载地址(以减少创建可利用模式的可能性)的任何尝试都将使这种情况变得常见，而不是罕见，因此，如果系统启用了此功能，则应尽一切努力编译所有共享对象库，使其独立于位置。|2308914|由于主程序主体对这些库的调用也将被重新定位，这使得必须复制共享库的可能性大大降低。|2308915|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

A minor addition to the answers already posted: object files not compiled to be position independent are relocatable; they contain relocation table entries.

These entries allow the loader (that bit of code that loads a program into memory) to rewrite the absolute addresses to adjust for the actual load address in the virtual address space.

An operating system will try to share a single copy of a "shared object library" loaded into memory with all the programs that are linked to that same shared object library.

Since the code address space (unlike sections of the data space) need not be contiguous, and because most programs that link to a specific library have a fairly fixed library dependency tree, this succeeds most of the time. In those rare cases where there is a discrepancy, yes, it may be necessary to have two or more copies of a shared object library in memory.

Obviously, any attempt to randomize the load address of a library between programs and/or program instances (so as to reduce the possibility of creating an exploitable pattern) will make such cases common, not rare, so where a system has enabled this capability, one should make every attempt to compile all shared object libraries to be position independent.

Since calls into these libraries from the body of the main program will also be made relocatable, this makes it much less likely that a shared library will have to be copied.

I have read about <a href="http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code-Gen-Options" rel="noreferrer">GCC's Options for Code Generation Conventions</a>, but could not understand what "Generate position-independent code (PIC)" does. Please give an example to explain me what does it mean.

GCC -fPIC option

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我读过关于的文章，但不明白“生成位置无关代码”的作用。请举一个例子来解释这是什么意思。

问GCC -fPIC期权
EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问GCC -fPIC期权EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问GCC -fPIC期权
EN