lld can't link 32-bit linux chrome |
|||||
Issue descriptionhttps://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Linux%20Builder%20%28dbg%29%2832%29/94238 ffmpeg_branding = "Chrome" is_component_build = true is_debug = true proprietary_codecs = true strip_absolute_paths_from_debug_symbols = true symbol_level = 1 target_cpu = "x86" use_goma = true goma_dir = "/b/s/w/ir/cache/goma/client" use_lld = true FAILED: libffmpeg.so libffmpeg.so.TOC python "../../build/toolchain/gcc_solink_wrapper.py" --readelf="readelf" --nm="nm" --sofile="./libffmpeg.so" --tocfile="./libffmpeg.so.TOC" --output="./libffmpeg.so" -- ../../third_party/llvm-build/Release+Asserts/bin/clang++ -shared -Wl,-Bsymbolic -L gen/third_party/ffmpeg -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -Wl,--as-needed -fuse-ld=lld -Wl,--icf=all -Wl,--color-diagnostics -m32 -Werror -rdynamic -nostdlib++ --sysroot=../../build/linux/debian_sid_i386-sysroot -L../../build/linux/debian_sid_i386-sysroot/usr/local/lib/i386-linux-gnu -Wl,-rpath-link=../../build/linux/debian_sid_i386-sysroot/usr/local/lib/i386-linux-gnu -L../../build/linux/debian_sid_i386-sysroot/lib/i386-linux-gnu -Wl,-rpath-link=../../build/linux/debian_sid_i386-sysroot/lib/i386-linux-gnu -L../../build/linux/debian_sid_i386-sysroot/usr/lib/i386-linux-gnu -Wl,-rpath-link=../../build/linux/debian_sid_i386-sysroot/usr/lib/i386-linux-gnu -L../../build/linux/debian_sid_i386-sysroot/usr/local/lib/i686-linux-gnu -Wl,-rpath-link=../../build/linux/debian_sid_i386-sysroot/usr/local/lib/i686-linux-gnu -L../../build/linux/debian_sid_i386-sysroot/lib/i686-linux-gnu -Wl,-rpath-link=../../build/linux/debian_sid_i386-sysroot/lib/i686-linux-gnu -L../../build/linux/debian_sid_i386-sysroot/usr/lib/i686-linux-gnu -Wl,-rpath-link=../../build/linux/debian_sid_i386-sysroot/usr/lib/i686-linux-gnu -o "./libffmpeg.so" -Wl,-soname="libffmpeg.so" @"./libffmpeg.so.rsp" ld.lld: error: can't create dynamic relocation R_386_32 against symbol: ff_h264_cabac_tables in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in obj/third_party/ffmpeg/ffmpeg_internal/cabac.o >>> referenced by cabac.h:192 (../../third_party/ffmpeg/libavcodec/x86/cabac.h:192) >>> obj/third_party/ffmpeg/ffmpeg_internal/h264_cabac.o:(ff_h264_decode_mb_cabac) ld.lld: error: can't create dynamic relocation R_386_32 against symbol: ff_h264_cabac_tables in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in obj/third_party/ffmpeg/ffmpeg_internal/cabac.o >>> referenced by cabac.h:192 (../../third_party/ffmpeg/libavcodec/x86/cabac.h:192) >>> obj/third_party/ffmpeg/ffmpeg_internal/h264_cabac.o:(ff_h264_decode_mb_cabac) ld.lld: error: can't create dynamic relocation R_386_32 against symbol: ff_h264_cabac_tables in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in obj/third_party/ffmpeg/ffmpeg_internal/cabac.o >>> referenced by cabac.h:192 (../../third_party/ffmpeg/libavcodec/x86/cabac.h:192) >>> obj/third_party/ffmpeg/ffmpeg_internal/h264_cabac.o:(ff_h264_decode_mb_cabac) ld.lld: error: can't create dynamic relocation R_386_32 against symbol: ff_h264_cabac_tables in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in obj/third_party/ffmpeg/ffmpeg_internal/cabac.o >>> referenced by cabac.h:192 (../../third_party/ffmpeg/libavcodec/x86/cabac.h:192) >>> obj/third_party/ffmpeg/ffmpeg_internal/h264_cabac.o:(ff_h264_decode_mb_cabac) ...etc. Works fine with gold.
,
Dec 4
Sounds like this is intentional from the lld side: http://lists.llvm.org/pipermail/llvm-dev/2017-March/111450.html We could add -Wl,-z,notext to the ffmpeg ldflags, or we could change ffmpeg to not hit this issue.
,
Dec 4
See also issue 782040
,
Dec 4
I believe that use of text relocation in ffmpeg is unintentional. That comes from inline assembly, right? I think a small tweak of the assembly should fix the issue.
,
Dec 4
I think the table comes form https://cs.chromium.org/chromium/src/third_party/ffmpeg/libavcodec/cabac.c?q=ff_h264_cabac_tables&sq=package:chromium&l=35&dr=C : DECLARE_ASM_ALIGNED(1, const uint8_t, ff_h264_cabac_tables)[512 + 4*2*64 + 4*64 + 63] = { 9,8,7,7,6,6,6,6,5,5,5,5,5,5,5,5,... https://cs.chromium.org/chromium/src/third_party/ffmpeg/libavutil/mem.h?type=cs&q=DECLARE_ASM_ALIGNED&sq=package:chromium&g=0&l=113 #define DECLARE_ASM_ALIGNED(n,t,v) t av_used __attribute__ ((aligned (n))) v https://cs.chromium.org/chromium/src/third_party/ffmpeg/libavutil/attributes.h?type=cs&q=av_used&sq=package:chromium&g=0&l=136 # define av_used __attribute__((used)) The references to it are apparently from https://cs.chromium.org/chromium/src/third_party/ffmpeg/libavcodec/x86/cabac.h?type=cs&q=ff_h264_cabac_tables&sq=package:chromium&g=0&l=52 (which has lots of inline asm and a BROKEN_RELOCATIONS define which we apparently set in x86_64 builds but not in i386 builds). dalecurtis, sounds more like an ffmpeg config issue than an lld issue -- can someone on your team look at this eventually? No urgency, but it blocks using lld in 32-bit linux builds.
,
Dec 4
We set that for MIPS already: https://cs.chromium.org/chromium/src/third_party/ffmpeg/chromium/scripts/build_ffmpeg.py?l=706 So fine with adding it for lld.
,
Dec 4
Whoops missed the above messages. Yeah we can reach out to the ffmpeg folks to see if BROKEN_RELOCATIONS is really what they want here: That comes from: https://chromium.googlesource.com/chromium/third_party/ffmpeg.git/+/e69364b700a6c0cb411ddc7737bc8e9e701d0cb8 So we can test just setting that #define too. https://chromium.googlesource.com/chromium/third_party/ffmpeg.git/+blame/HEAD/libavutil/x86/asm.h#78
,
Dec 4
=>chcunningham as part of the ffmpeg roll.
,
Dec 12
(A comment on https://chromium-review.googlesource.com/c/chromium/src/+/1361321 mentions this is an issue on mips too.)
,
Dec 18
,
Jan 2
,
Jan 2
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by thakis@chromium.org
, Dec 4