[FFmpeg-devel] Why do we use `strip -wN` instead of the more general `strip -x`?

James Darnley james.darnley at gmail.com
Fri May 12 03:20:44 EEST 2017

I want to discuss why we use this and argue that we should be using
`strip -x` all the time anyway.

The man page for strip says that -x removes all non-global symbols.  -wN
is a combination of -w for wildcard matching and -N to remove a given

-wN gets ..@* as an argument.  Together they remove the symbols
generated by nasm/yasm and the x264asm layer for branch instructions
(and maybe other things).  Macro local labels generated by the
preprocessor with %%[1] are also of this form and will get removed.

Unfortunately that does not remove the common local labels we use
throughout the assembly code.  In the output object these labels get
prepended by the previous non-local label.[2]  Meaning you get
function1.label1, function1.label2, function2.label1, and function2.label2.

These remaining symbols can cause confusion for both tools and by
extension developers.  I will use the function
ff_h264_idct_add16intra_8_sse2 as an extreme example (from the file
libavcodec/x86/h264_idct.asm).  This function gets many local labels
because it uses the preprocessor to create them in a macro call.

Objdump is a tool which shows the issue quite easily.

> 0000000000002b20 <ff_h264_idct_add16intra_8_sse2>:
> 0000000000002b3c <ff_h264_idct_add16intra_8_sse2.try0dc>:
> 0000000000002b50 <ff_h264_idct_add16intra_8_sse2.cycle0end>:
> 0000000000002b6b <ff_h264_idct_add16intra_8_sse2.try1dc>:
> 0000000000002b80 <ff_h264_idct_add16intra_8_sse2.cycle1end>:
> 0000000000002b9b <ff_h264_idct_add16intra_8_sse2.try2dc>:
> 0000000000002bb0 <ff_h264_idct_add16intra_8_sse2.cycle2end>:
> 0000000000002bcb <ff_h264_idct_add16intra_8_sse2.try3dc>:
> 0000000000002be0 <ff_h264_idct_add16intra_8_sse2.cycle3end>:
> 0000000000002bfb <ff_h264_idct_add16intra_8_sse2.try4dc>:
> 0000000000002c10 <ff_h264_idct_add16intra_8_sse2.cycle4end>:
> 0000000000002c2b <ff_h264_idct_add16intra_8_sse2.try5dc>:
> 0000000000002c40 <ff_h264_idct_add16intra_8_sse2.cycle5end>:
> 0000000000002c5b <ff_h264_idct_add16intra_8_sse2.try6dc>:
> 0000000000002c70 <ff_h264_idct_add16intra_8_sse2.cycle6end>:
> 0000000000002c8b <ff_h264_idct_add16intra_8_sse2.try7dc>:
> 0000000000002ca0 <ff_h264_idct_add16intra_8_sse2.cycle7end>:

The disassembled function gets split between all these labels.

Perf is another tool which shows the issue.  Its recording of time spent
in a function gets split among the labels.  Useful to see at a glance if
a particular loop is exceptionally slow (if the labels are used for a
loop).  Less useful if the labels split the time into several pieces
making each one look "quick".

The worst is what I heard on IRC from, I think, Ronald.  He told me that
when he tries to disassemble a function in gdb it will only print the
top of the function until it reaches the next label.  I guess it thinks
that is another function.

It is these reasons that I think we should be using -x all the time.  Do
we gain anything from leaving these symbols in the assembly objects?  Do
we lose something is we use -x?

I welcome your comments.

[1] http://www.nasm.us/xdoc/2.13.01/html/nasmdoc4.html#section-4.3.2
[2] http://www.nasm.us/xdoc/2.13.01/html/nasmdoc3.html#section-3.9

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170512/f567f077/attachment.sig>

More information about the ffmpeg-devel mailing list