Hey Martin, It's nice to see you on this mailing list!
Sorry about sending this email as a reply to a wrong email, as I didn't receive your mail and thus couldn't send this as a reply to your mail. > On Sat, 7 Jan 2023, Rui Ueyama wrote: > > > It looks like compiler-generated code always uses `b`, `bl` or `blx` > > instructions for function calls. These instructions have a 24-bit > > immediate and therefore can jump anywhere between PC +- 16 MiB. > > > > This hand-written assembly code instead uses `bge` and `beq` for > > interprocedural jumps. Since these instructions have only a 19-bit > > immediate (we have less bits for condition code), they can jump only > > within PC +- 512 KiB. This sometimes causes a "relocation R_ARM_THM_JUMP19 > > out of range" error when linked with the mold linker. This error can > > easily be avoided by using `b` instead of `bge` or `beq`. > > Can you add a bit more explanation about what happens in mold in this case > and context about the setup - I don't quite understand how this can happen > (even if the code admittedly is a bit unusual)? > > Since .L_swri_oldapi_conv_flt_to_s16_neon and > .L_swri_oldapi_conv_fltp_to_s16_2ch_neon are local symbols, they don't get > emitted by the assembler, and the branch instructions are encoded with > fixed offsets and no relocations. And even if there would be a relocation, > the destination is within the same text section chunk in the object file, > so it shouldn't be possible for it to be out of range. > > The only possibility for this to be out of range, is if the destination is > treated as a global and routed via the PLC? There was confusion on our side. ffmpeg used to contain two audio_convert_neon.S as below libswresample/arm/audio_convert_neon.S libavresample/arm/audio_convert_neon.S and the latter had a problem that I explained in the previous mail. But that file has been removed, so there's no problem with the existing code. I'll retract the patch I sent before. Sorry for the confusion. Rui _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".