I recently downloaded the h.264 reference code from Fraunhofer ( http://iphome.hhi.de/suehring/ ), and built it using berkely riscv-unknown-elf-gcc (-O2 -march=rv32imac -mabi=ilp32)
I’m focusing on code size, and both riscv-unknown-elf-readelf / riscv-unknown-elf-nm show some functions to be 0xfffffffe bytes long !?
‘riscv-unknown-elf-objdump -d’ shows these functions to be a single, 16b ‘ret’
.elf available on-demand (can’t upload it), functions init_time / interpret_user_data_registered_itu_t_t35_info / interpret_full_frame_freeze_release_info, for instance
‘riscv-unknown-elf-readelf -s ldecode.exe | grep fffffffe’ exhibits the bug
Is this a known bug in the toolchain ? A misuse on my side ?
Yes, there are known bugs with symbol sizes. This is due to the linker relaxation support which can delete instructions at link time. This requires updating symbol addresses and sizes while deleting code, and this gets tricky because there are complicated interactions with other linker features. This has been fixed in the upstream FSF tree, but there were multiple patches required to get this right, so the only source tree that gets this right at the moment is the top of the FSF binutils tree.
If you have a recent enough source tree, e.g. binutils-2.30, then you might be able to fix it by backporting a few patches. These patches may eventually get backported into the riscv-gnu-toolchain binutils-2.30 branch.