The -fPIC flag changes how the compiler generates machine instructions for several common operations. Instead of referencing absolute memory addresses, PIC code uses relative addressing and an indirection table called the Global Offset Table (GOT).

The -fPIC flag affects how the compiler handles these specific situations:

The key mechanism behind PIC is the Global Offset Table (GOT). This is a table of pointers stored in the data segment of the shared library. Each entry holds the absolute run-time address of a symbol (global variable or function).

At run time, when the dynamic linker loads the library, it patches the GOT entries with the correct absolute addresses for that process’s virtual address space. The code itself never changes — only the GOT (which is per-process data) gets patched.

The symbol _GLOBAL_OFFSET_TABLE_ appears in the symbol table of any object file compiled with -fPIC. Its presence is how you verify that PIC was used.

The reason is fundamental to how virtual memory and shared memory work. When the kernel maps a shared library into multiple processes, it maps the same physical memory pages for the code (text) segment. If that code contained absolute addresses, those addresses would only be correct for the one process that happens to have the library at that exact virtual address.

With PIC, the code is truly read-only and address-agnostic. Every process sees the same machine instructions, which access data through the GOT. The GOT differs per process (it lives in private data pages), so each process can have the library at a different virtual address and still work correctly.

PIC code has a small performance overhead compared to non-PIC code. The overhead comes from:

• Extra register usage: On 32-bit x86, PIC code uses an extra register (typically ebx) to hold the GOT pointer. This register is no longer available for general computation, which can force the compiler to spill other values to the stack. On 64-bit x86 (x86-64), this overhead is negligible because PC-relative addressing is directly supported in the instruction set.
• Indirect memory accesses: Accessing a global variable requires one extra memory load (fetch the address from the GOT, then fetch the variable). Modern CPUs with large caches make this overhead negligible in practice.

In practice, the PIC overhead is small enough that most modern applications do not notice it, especially on 64-bit systems. The benefits of shared libraries far outweigh this cost.

Two ways to check if an object file was compiled with -fPIC:

# Method 1: nm — look for _GLOBAL_OFFSET_TABLE_ symbol
nm mod1.o | grep _GLOBAL_OFFSET_TABLE_

# If PRESENT:  file was compiled WITH -fPIC
# If ABSENT:   file was compiled WITHOUT -fPIC

# Method 2: readelf — same check via ELF symbol table
readelf -s mod1.o | grep _GLOBAL_OFFSET_TABLE_

Two ways to check if a shared library contains non-PIC code:

# Method 1: objdump — look for TEXTREL flag
objdump --all-headers libfoo.so | grep TEXTREL

# Method 2: readelf — check dynamic section
readelf -d libfoo.so | grep TEXTREL

# TEXTREL present = at least one module was NOT compiled with -fPIC
# This means those text pages CANNOT be shared between processes
# Each process gets its own modified copy — memory is wasted

This example compares the assembler output of GCC with and without -fPIC. You can see how global variable access changes.

/* pic_demo.c — accesses a global variable and calls an external function */
#include <stdio.h>

int global_counter = 0;   /* global variable — in .data */

void increment_global(void) {
    global_counter++;
}

int get_global(void) {
    return global_counter;
}

# Compile WITHOUT -fPIC and dump assembly
gcc -O0 -c pic_demo.c -o no_pic.o
objdump -d no_pic.o
# In the output you will see direct absolute-address references
# Example (x86-32): mov 0x0, %eax  (address 0x0 to be patched by linker)

# Compile WITH -fPIC and dump assembly
gcc -O0 -c -fPIC pic_demo.c -o with_pic.o
objdump -d with_pic.o
# In the output you see GOT-relative addressing
# Example: call __x86.get_pc_thunk.ax; add $_GLOBAL_OFFSET_TABLE_, %eax

# Verify _GLOBAL_OFFSET_TABLE_ presence
nm no_pic.o | grep GLOBAL_OFFSET   # no output
nm with_pic.o | grep GLOBAL_OFFSET # shows the symbol

# Check object file sizes (with_pic.o slightly larger)
ls -l no_pic.o with_pic.o

# On x86-64 the difference is less dramatic because x86-64 has
# native PC-relative addressing. On 32-bit x86 the difference
# in assembly is much more visible.
# To see 32-bit output on 64-bit machine:
gcc -m32 -O0 -c pic_demo.c -o no_pic_32.o
gcc -m32 -O0 -c -fPIC pic_demo.c -o with_pic_32.o
objdump -d no_pic_32.o
objdump -d with_pic_32.o

This is a practical script that builds a library, deliberately introduces a non-PIC module, and shows how the TEXTREL check detects the problem.

/* good.c — compiled WITH -fPIC */
#include <stdio.h>
int good_value = 42;
void good_func(void) {
    printf("good_func: good_value = %d\n", good_value);
}

/* bad.c — will be compiled WITHOUT -fPIC (intentionally) */
#include <stdio.h>
int bad_value = 99;
void bad_func(void) {
    printf("bad_func: bad_value = %d\n", bad_value);
}

# Step 1: Compile good.c correctly WITH -fPIC
gcc -c -fPIC -Wall good.c -o good.o

# Step 2: Compile bad.c WITHOUT -fPIC (simulates a mistake)
gcc -c -Wall bad.c -o bad.o

# Step 3: Check each .o for _GLOBAL_OFFSET_TABLE_
echo "=== good.o (should have GOT symbol) ==="
nm good.o | grep _GLOBAL_OFFSET_TABLE_ || echo "NOT FOUND — not PIC!"

echo "=== bad.o (should be missing GOT symbol) ==="
nm bad.o | grep _GLOBAL_OFFSET_TABLE_ || echo "NOT FOUND — not PIC!"

# Step 4: Build shared library mixing PIC and non-PIC objects
# gcc will warn about this on some systems
gcc -shared -o libmixed.so good.o bad.o

# Step 5: Check the resulting .so for TEXTREL
echo "=== TEXTREL check on libmixed.so ==="
readelf -d libmixed.so | grep TEXTREL
# If bad.o was non-PIC you WILL see TEXTREL here

echo "=== Build a correct library (all -fPIC) ==="
gcc -c -fPIC -Wall bad.c -o bad_pic.o    # recompile WITH -fPIC
gcc -shared -o libgood.so good.o bad_pic.o

echo "=== TEXTREL check on libgood.so (should be empty) ==="
readelf -d libgood.so | grep TEXTREL || echo "No TEXTREL — all modules are PIC"

# Step 6: Verify _GLOBAL_OFFSET_TABLE_ in both .o files
nm good.o | grep GLOBAL_OFFSET_TABLE
nm bad_pic.o | grep GLOBAL_OFFSET_TABLE
# Both should show the symbol now

# Step 7: Bonus — use 'file' to confirm the .so type
file libgood.so
# ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
# dynamically linked, not stripped

# Step 8: Use readelf to see GOT in section headers
readelf -S libgood.so | grep -E "(Name|\.got|\.plt)"
# You will see .got, .got.plt sections in the output