On 2019-10-30 00:17, Steve McIntyre wrote: > Source: glibc > Version: 2.28-10 > Severity: important > > Hi folks, > > It looks like my old Arm ABI detection patch for ld.so is causing > problems for people using LLVM. I've been contacted by a developer, > referring to a mailing list thread: > > https://lists.llvm.org/pipermail/llvm-dev/2019-October/135993.html > > It looks like the LLVM version of strip is more aggressive than the > GNU binutils version, and this is causing problems - it's stripping > the .ARM.attributes data and that's causing problems with our extra > checks for the Tag_ABI_VFP_args setting. Whether that's a valid thing > to do or not is an argument for another day, I think... However, > checking with the bzip2 binaries that the reporter provided I can see > that they have the right ABI flag in the ELF header but we're still > running the extra ABI check: > > (sid-armhf)steve@mjolnir:~/abi$ LD_PRELOAD=./libbz2.so.all ./bzip2 > ERROR: ld.so: object './libbz2.so.all' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > bzip2: I won't write compressed data to a terminal. > bzip2: For help, type: `bzip2 --help'. > > (sid-armhf)steve@mjolnir:~/abi$ readelf -a libbz2.so.all | grep "^ Flags" > Flags: 0x5000400, Version5 EABI, hard-float ABI > > I think this is wrong, and I can't think of why I didn't find this > earlier when I was working in this area. :-/ > > So: I think we have two sensible options: > > 1. I find time now to fix up ld.so to only do the extra check here if > we think it's needed > > OR > > 2. Just remove the patch for extra check here - it was always the plan > that this would go away after a while once people were unlikely to > still be running binaries from the pre ELF-header toolchains. > > Checking history, I can see that the binutils changes for those ELF > header changes landed in Debian back in Nov 2012. (Wow, time > flies!). Given that, I'd now be strongly in favour of just dropping the > patch in > > debian/patches/arm/unsubmitted-ldso-abi-check.diff > > as it's now safely obsolete. What do others think?
Given this patch is not needed anymore, I also thing it's the way to do. It caused us issue in the past, so i'll be very happy to see it going away. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net