c - Why do .bss/.rodata symbols stay in binary after strip? -

c - Why do .bss/.rodata symbols stay in binary after strip? -

as far know, there's 1 kind of symbols in executable binary needed, dynamic symbols. these symbols used in relocation operation because dynamic linked. static linked functions/variables, in other hand, not needed can stripped.

however, when examining stripped ffmpeg binary, got:

>nm -d ffmpeg ... u __vfprintf_chk u __vsnprintf_chk u write 00000000018fa880 b x264_cabac_contexts 0000000001052a40 r x264_cabac_range_lps 0000000001052940 r x264_cabac_transition 0000000001970580 b x264_cabac_transition_unary 0000000001056820 r x264_last_coeff_flag_offset 0000000001056860 r x264_significant_coeff_flag_offset 0000000001056900 r x264_significant_coeff_flag_offset_8x8 u __xpg_strerror_r u __xstat64 ...

i can verify libx264 static linked ffmpeg:

> ldd ffmpeg linux-vdso.so.1 => (0x00007fff26d61000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f7c707e7000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7c704e1000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f7c702be000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f7c700ae000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f7c6fe95000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7c6fc76000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7c6f8b0000) /lib64/ld-linux-x86-64.so.2 (0x00007f7c70b0a000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f7c6f69a000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7c6f495000)

so, don't understand why symbols x264_cabac_contexts not stripped. (it's defined in libx264/.../cabac.c):

uint8_t x264_cabac_contexts[4][qp_max_spec+1][1024];

it bothered me several hours , i've found nil on google... hope explain this... in advance!

as far know, there's 1 kind of symbols in executable binary needed, dynamic symbols.

correct.

so, don't understand why symbols x264_cabac_contexts not stripped.

because dynamic symbols (that's nm -d printing).

the question should asking not why dynamic symbols aren't stripped, why x264_cabac_contexts dynamic symbol.

there 2 answers:

either ffmpeg binary linked --export-dynamic or equivalent flag, or the symbol referenced shared library participated in link.

looking @ list of shared libraries in ldd output, reply #2 seems unlikely. reply #1 correct.

no, i'm not compiling -rdynamic

compiling has nil this. it's linking matters. didn't show link command, has some flag means "export symbols" (i.e. equivalent -rdynamic). or utilize linker script same.

c gcc ffmpeg linker elf