Bug#870622: ffmpeg: autopkgtest SIGBUS on armhf with binutils 2.29
(Just for the record to avoid misleading) I think the .eqv should fully work, but need to correct the reason for why. It is not because it turned the new symbol into non-function type, but because .eqv is expect to always evaulate the snapshot value of the equaled expression at each place the new symbol is used, you don't know it's final value and the associated section, therefore it is associated with undefined section until the final stage of assembling. So, when doing ADR instruction assembling, at that stage, the new symbol is still without definition section assigned, therefore is able to skip the LSB setting which only happens for thumb function symbol with defined section. binutils-gdb/gas/config/tc-arm.c: do_t_adr ... && S_IS_DEFINED (inst.reloc.exp.X_add_symbol) && THUMB_IS_FUNC (inst.reloc.exp.X_add_symbol)) inst.reloc.exp.X_add_number += 1; Use .equ, the magic disappear. Regards, Jiong On 04/08/17 14:58, Jiong Wang wrote: Change "adreq lr,X(ff_h264_idct_add_neon) +CONFIG_THUMB" Into: .eqv ff_h264_idct_add_neon_without_func_type, X(ff_h264_idct_add_neon) adreq lr,ff_h264_idct_add_neon_without_func_type +CONFIG_THUMB might be a solution. The idea is we use .eqv to remove the function attribute, so the assembler won't set LSB in any case. On 04/08/17 12:39, Jiong Wang wrote: Hi, This issue is caused by a recent change in ARM assembler included since Binutils 2.29. The details of that change can be found at https://sourceware.org/bugzilla/show_bug.cgi?id=21458 The semantics of ADR has changed. In general, the address generated by ADR will guarantee the LSB be set if it's a thumb function address. I noticed h264idct_neon.S is using something like: adreq lr,X(ff_h264_idct_add_neon) +CONFIG_THUMB As ADR now will set the LSB automatically, you don't need CONFIG_THUMB any more. I think h264idct_neon.S needs to be updated, and the modification should make sure it works with both old Binutils and the new one. Regards, Jiong ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#870622: ffmpeg: autopkgtest SIGBUS on armhf with binutils 2.29
On 5 August 2017 at 17:33, James Cowgill wrote: > Hi, > > On 04/08/17 09:58, Jiong Wang wrote: >> Change >> >> "adreq lr,X(ff_h264_idct_add_neon) +CONFIG_THUMB" >> >> Into: >> >> .eqv ff_h264_idct_add_neon_without_func_type, X(ff_h264_idct_add_neon) >> adreq lr, ff_h264_idct_add_neon_without_func_type +CONFIG_THUMB >> >> might be a solution. The idea is we use .eqv to remove the function >> attribute, so the assembler won't set LSB in any case. > On the technical side, does having the LSB clear when executing a blx > instruction cause a mode change out of Thumb, or does it retain the > mode? I think all the code in that file is compiled in the same mode, so > if the mode is retained then simply dropping +CONFIG_THUMB might work. All the usual register branch instructions set or reset T32 (Thumb) mode according to bit 0 of the target address. This is to enable "interworking": an A32 function can call a T32 function and vice versa. What Jiong suggested, above, looks like the right solution for now. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#870622: ffmpeg: autopkgtest SIGBUS on armhf with binutils 2.29
Hi, On 04/08/17 09:58, Jiong Wang wrote: > Change > > "adreq lr,X(ff_h264_idct_add_neon) +CONFIG_THUMB" > > Into: > > .eqv ff_h264_idct_add_neon_without_func_type, X(ff_h264_idct_add_neon) > adreq lr, ff_h264_idct_add_neon_without_func_type +CONFIG_THUMB > > might be a solution. The idea is we use .eqv to remove the function > attribute, so the assembler won't set LSB in any case. This was the commit which introduced the +CONFIG_THUMB stuff: https://github.com/FFmpeg/FFmpeg/commit/8986fddc2bab92bd7d77a123ac70c4fb70c96c7c On the technical side, does having the LSB clear when executing a blx instruction cause a mode change out of Thumb, or does it retain the mode? I think all the code in that file is compiled in the same mode, so if the mode is retained then simply dropping +CONFIG_THUMB might work. Would it be possible for you or someone with better ARM assembly experience to submit the fixes upstream? It would help greatly. On Debian, there is #870676 open about NEON code on ARM. We could "fix" this bug and that one by disabling NEON but it would be nice if we didn't have to do that. Thanks, James > On 04/08/17 12:39, Jiong Wang wrote: >> Hi, >> >> This issue is caused by a recent change in ARM assembler included >> since Binutils 2.29. >> >> The details of that change can be found at >> https://sourceware.org/bugzilla/show_bug.cgi?id=21458 >> >> The semantics of ADR has changed. In general, the address generated >> by ADR will guarantee the LSB be set if it's a thumb function address. >> >>I noticed h264idct_neon.S is using something like: >> >> adreq lr,X(ff_h264_idct_add_neon) +CONFIG_THUMB >> >>As ADR now will set the LSB automatically, you don't need >> CONFIG_THUMB any more. >> >>I think h264idct_neon.S needs to be updated, and the modification >> should make sure it works with both old Binutils and the new one. >> >> Regards, >> Jiong signature.asc Description: OpenPGP digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#870622: ffmpeg: autopkgtest SIGBUS on armhf with binutils 2.29
Change "adreq lr,X(ff_h264_idct_add_neon) +CONFIG_THUMB" Into: .eqv ff_h264_idct_add_neon_without_func_type, X(ff_h264_idct_add_neon) adreq lr,ff_h264_idct_add_neon_without_func_type +CONFIG_THUMB might be a solution. The idea is we use .eqv to remove the function attribute, so the assembler won't set LSB in any case. On 04/08/17 12:39, Jiong Wang wrote: Hi, This issue is caused by a recent change in ARM assembler included since Binutils 2.29. The details of that change can be found at https://sourceware.org/bugzilla/show_bug.cgi?id=21458 The semantics of ADR has changed. In general, the address generated by ADR will guarantee the LSB be set if it's a thumb function address. I noticed h264idct_neon.S is using something like: adreq lr,X(ff_h264_idct_add_neon) +CONFIG_THUMB As ADR now will set the LSB automatically, you don't need CONFIG_THUMB any more. I think h264idct_neon.S needs to be updated, and the modification should make sure it works with both old Binutils and the new one. Regards, Jiong ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#870622: ffmpeg: autopkgtest SIGBUS on armhf with binutils 2.29
On 04.08.2017 07:39, Jiong Wang wrote: > Hi, > > This issue is caused by a recent change in ARM assembler included since > Binutils 2.29. > > The details of that change can be found at > https://sourceware.org/bugzilla/show_bug.cgi?id=21458 > > The semantics of ADR has changed. In general, the address generated by ADR > will guarantee the LSB be set if it's a thumb function address. > >I noticed h264idct_neon.S is using something like: > > adreq lr,X(ff_h264_idct_add_neon) +CONFIG_THUMB > >As ADR now will set the LSB automatically, you don't need CONFIG_THUMB any > more. > >I think h264idct_neon.S needs to be updated, and the modification should > make > sure it works with both old Binutils and the new one. thanks for looking into that. Also noted that the Debian armhf architecture cannot assume neon, so maybe we should disable the use of neon in ffmpeg on armhf? Matthias ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#870622: ffmpeg: autopkgtest SIGBUS on armhf with binutils 2.29
Hi, This issue is caused by a recent change in ARM assembler included since Binutils 2.29. The details of that change can be found at https://sourceware.org/bugzilla/show_bug.cgi?id=21458 The semantics of ADR has changed. In general, the address generated by ADR will guarantee the LSB be set if it's a thumb function address. I noticed h264idct_neon.S is using something like: adreq lr,X(ff_h264_idct_add_neon) +CONFIG_THUMB As ADR now will set the LSB automatically, you don't need CONFIG_THUMB any more. I think h264idct_neon.S needs to be updated, and the modification should make sure it works with both old Binutils and the new one. Regards, Jiong ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#870622: ffmpeg: autopkgtest SIGBUS on armhf with binutils 2.29
On 03/08/17 14:07, James Cowgill wrote:
Source: ffmpeg
Version: 7:3.3.3-1
Severity: important
Tags: sid buster
X-Debbugs-CC: debian-...@lists.debian.org, binut...@packages.debian.org
Hi,
I was looking at the Ubuntu proposed migration pages for ffmpeg and
noticed that the autopkgtest failed on armhf:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/armhf/f/ffmpeg/20170803_033623_bd98d@/log.gz
It fails with SIGBUS when running the h264 tests.
(gdb) bt
#0 0xf6456e12 in ff_h264_idct_add_neon () at
src/libavcodec/arm/h264idct_neon.S:24
#1 0xf6456f3c in ff_h264_idct_add16_neon () at
src/libavcodec/arm/h264idct_neon.S:118
#2 0xf659c88c in hl_decode_mb_idct_luma (p=, dest_y=,
linesize=, block_offset=, pixel_shift=0, transform_bypass=0,
simple=1,
mb_type=, sl=, h=) at
src/libavcodec/h264_mb.c:778
#3 hl_decode_mb_444_simple_8 (h=0xaab6ea00, sl=) at
src/libavcodec/h264_mb_template.c:349
#4 0xf65a471e in ff_h264_hl_decode_mb (h=h@entry=0xaab6ea00,
sl=sl@entry=0xaab7a080) at src/libavcodec/h264_mb.c:810
#5 0xf65b3670 in decode_slice (avctx=,
arg=arg@entry=0xaab7a080) at src/libavcodec/h264_slice.c:2553
#6 0xf65b45a6 in ff_h264_execute_decode_slices (h=h@entry=0xaab6ea00) at
src/libavcodec/h264_slice.c:2728
#7 0xf65b954a in decode_nal_units (buf_size=20, buf=0xaab35f00 "",
h=0xaab6ea00) at src/libavcodec/h264dec.c:715
#8 h264_decode_frame (avctx=0xaab0d850, data=0xaab0dc70, got_frame=0xaab38a2c,
avpkt=) at src/libavcodec/h264dec.c:1016
#9 0xf679c8e2 in frame_worker_thread (arg=0xaab38908) at
src/libavcodec/pthread_frame.c:199
#10 0xf61895e8 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
#11 0xf612a57c in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
(gdb) print $pc
$1 = (void (*)()) 0xf6456e12
(gdb) disassemble
Dump of assembler code for function ff_h264_idct_add_neon:
0xf6456e10 <+0>: vld1.64 {d0-d3}, [r1 :128]
0xf6456e14 <+4>: vmov.i16q15, #0 ; 0x
0xf6456e18 <+8>: vswpd1, d2
0xf6456e1c <+12>:vst1.16 {d30-d31}, [r1 :128]!
Notice that the program counter is misaligned - there is no instruction
at 0xf6456e12.
Since nothing has been changed in h264idct_neon.S for > 2 years, I
guessed a toolchain issue and sure enough there is a difference
between compiling the same file with binutils 2.28 and 2.29:
--- h264idct_neon-binutils-2.28-5 2017-08-03 12:48:07.560036237 +
+++ h264idct_neon-binutils-2.29-3 2017-08-03 12:47:43.666083113 +
@@ -89,8 +89,8 @@
118: f04f 0e00 movne.w lr, #0
11c: f1be 0f00 cmp.w lr, #0
120: bf14ite ne
- 122: f2af 0e7f subwne lr, pc, #127; 0x7f
- 126: f2af 1e27 subweq lr, pc, #295; 0x127
+ 122: f2af 0e7e subwne lr, pc, #126; 0x7e
+ 126: f2af 1e26 subweq lr, pc, #294; 0x126
12a: 47f0blx lr
12c: f1bc 0c01 subs.w ip, ip, #1
130: f101 0120 add.w r1, r1, #32
[...]
Could the ARM porters look and see if the assembly in h264idct_neon.S is
sane? If it is, this is probably a binutils bug.
While I haven't looked at the source the LSB of a code pointer indicates
whether the system is in arm mode or thumb mode. It looks like in the old
binary is performing a mode switch while in the new binary is not.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#870622: ffmpeg: autopkgtest SIGBUS on armhf with binutils 2.29
Source: ffmpeg
Version: 7:3.3.3-1
Severity: important
Tags: sid buster
X-Debbugs-CC: debian-...@lists.debian.org, binut...@packages.debian.org
Hi,
I was looking at the Ubuntu proposed migration pages for ffmpeg and
noticed that the autopkgtest failed on armhf:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/armhf/f/ffmpeg/20170803_033623_bd98d@/log.gz
It fails with SIGBUS when running the h264 tests.
> (gdb) bt
> #0 0xf6456e12 in ff_h264_idct_add_neon () at
> src/libavcodec/arm/h264idct_neon.S:24
> #1 0xf6456f3c in ff_h264_idct_add16_neon () at
> src/libavcodec/arm/h264idct_neon.S:118
> #2 0xf659c88c in hl_decode_mb_idct_luma (p=,
> dest_y=, linesize=, block_offset= out>, pixel_shift=0, transform_bypass=0, simple=1,
> mb_type=, sl=, h=) at
> src/libavcodec/h264_mb.c:778
> #3 hl_decode_mb_444_simple_8 (h=0xaab6ea00, sl=) at
> src/libavcodec/h264_mb_template.c:349
> #4 0xf65a471e in ff_h264_hl_decode_mb (h=h@entry=0xaab6ea00,
> sl=sl@entry=0xaab7a080) at src/libavcodec/h264_mb.c:810
> #5 0xf65b3670 in decode_slice (avctx=,
> arg=arg@entry=0xaab7a080) at src/libavcodec/h264_slice.c:2553
> #6 0xf65b45a6 in ff_h264_execute_decode_slices (h=h@entry=0xaab6ea00) at
> src/libavcodec/h264_slice.c:2728
> #7 0xf65b954a in decode_nal_units (buf_size=20, buf=0xaab35f00 "",
> h=0xaab6ea00) at src/libavcodec/h264dec.c:715
> #8 h264_decode_frame (avctx=0xaab0d850, data=0xaab0dc70,
> got_frame=0xaab38a2c, avpkt=) at src/libavcodec/h264dec.c:1016
> #9 0xf679c8e2 in frame_worker_thread (arg=0xaab38908) at
> src/libavcodec/pthread_frame.c:199
> #10 0xf61895e8 in start_thread () from
> /lib/arm-linux-gnueabihf/libpthread.so.0
> #11 0xf612a57c in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
> (gdb) print $pc
> $1 = (void (*)()) 0xf6456e12
> (gdb) disassemble
> Dump of assembler code for function ff_h264_idct_add_neon:
>0xf6456e10 <+0>: vld1.64 {d0-d3}, [r1 :128]
>0xf6456e14 <+4>: vmov.i16q15, #0 ; 0x
>0xf6456e18 <+8>: vswpd1, d2
>0xf6456e1c <+12>:vst1.16 {d30-d31}, [r1 :128]!
Notice that the program counter is misaligned - there is no instruction
at 0xf6456e12.
Since nothing has been changed in h264idct_neon.S for > 2 years, I
guessed a toolchain issue and sure enough there is a difference
between compiling the same file with binutils 2.28 and 2.29:
> --- h264idct_neon-binutils-2.28-5 2017-08-03 12:48:07.560036237 +
> +++ h264idct_neon-binutils-2.29-3 2017-08-03 12:47:43.666083113 +
> @@ -89,8 +89,8 @@
> 118: f04f 0e00 movne.w lr, #0
> 11c: f1be 0f00 cmp.w lr, #0
> 120: bf14ite ne
> - 122: f2af 0e7f subwne lr, pc, #127; 0x7f
> - 126: f2af 1e27 subweq lr, pc, #295; 0x127
> + 122: f2af 0e7e subwne lr, pc, #126; 0x7e
> + 126: f2af 1e26 subweq lr, pc, #294; 0x126
> 12a: 47f0blx lr
> 12c: f1bc 0c01 subs.w ip, ip, #1
> 130: f101 0120 add.w r1, r1, #32
[...]
Could the ARM porters look and see if the assembly in h264idct_neon.S is
sane? If it is, this is probably a binutils bug.
Thanks,
James
signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
