From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 82C21433C2 for ; Sun, 10 Jul 2022 22:17:24 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 7147668B7E6; Mon, 11 Jul 2022 01:17:21 +0300 (EEST) Received: from mail8.parnet.fi (mail8.parnet.fi [77.234.108.134]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 9489768B736 for ; Mon, 11 Jul 2022 01:17:14 +0300 (EEST) Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21]) by mail8.parnet.fi with ESMTP id 26AMHDvY013762-26AMHDvZ013762 for ; Mon, 11 Jul 2022 01:17:13 +0300 Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187]) by mail9.parnet.fi (Postfix) with ESMTPS id 74821A150B for ; Mon, 11 Jul 2022 01:17:13 +0300 (EEST) Date: Mon, 11 Jul 2022 01:17:12 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: FFmpeg development discussions and patches In-Reply-To: <82e16738-3cb3-b4e8-cab5-10e9f58622c4@yandex.ru> Message-ID: <7542af15-2e7-eba5-8a97-b8eb8ce8c8d9@martin.st> References: <82e16738-3cb3-b4e8-cab5-10e9f58622c4@yandex.ru> MIME-Version: 1.0 X-FE-Policy-ID: 3:14:2:SYSTEM Subject: Re: [FFmpeg-devel] [PATCH] avcodec/aarch64: Access externs via GOT with PIC X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Hi, Thanks for your patch! While the patch probably is worthwhile to pursue, ffmpeg does work on Android 6 and newer (with the aarch64 assembly), so there's some gaps/misses in the reasoning in the patch description. On Sun, 10 Jul 2022, Triang3l wrote: > To support PIC, all AArch64 assembly code in FFmpeg uses the `movrel` > macro to obtain addresses of labels, such as lookup table constants, in > a way that with CONFIG_PIC being 1, PC-relative addresses of labels are > computed via the `adrp` instruction. > This approach, however, is suitable only for labels defined in the same > object file. For `adrp` to work directly between object files, the > linker has to perform a text relocation. No, it doesn't. It's fully possible to build such libraries without text relocations currently. My memory of the situation was that we're linking our shared libraries with -Wl,-Bsymbolic, which means that those symbol references are bound at link time, so the offset from adrp to the target symbol is fixed at link time, and no text relocation is needed. However I did try to link such shared libraries, removing the -Wl,-Bsymbolic argument, and it still succeeds. So I'm a bit unsure what really makes it work for me when it isn't working for you. With Android NDK r24, I configured a build with "-target-os=android --arch=aarch64 --cc=aarch64-linux-android32-clang --enable-cross-compile --enable-shared", and successfully build that. The built libavcodec.so.59 does not have text relocations. Can you reproduce and confirm this bit? > And in my scenario (libavcodec being a static library linked > to a shared library, though I'm not sure if this is relevant), I think this might be quite relevant. Does adding -Wl,-Bsymbolic to the linker invocation when linking in the static libavcodec into your shared library fix the issue? (I'm not necessarily arguing that we shouldn't fix this issue - but I want to know exactly what differs in your setup and what detail exactly makes it work in our current default builds which is missing in yours.) > Windows has no concept of PIC, and Windows builds should be done > with CONFIG_PIC being 0, so it doesn't need to be handled. While Windows doesn't really have proper PIC, common builds of ffmpeg on Windows on aarch64 do end up with CONFIG_PIC set to 1, so please do handle that in the movrelx macro too, expanding to the same as the current movrel macro for those cases. // Martin _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".