Bug#943798: ld.so: old Arm ABI detection patch causing problems, time to remove?
On Fri, Nov 01, 2019 at 10:22:14AM +0100, Aurelien Jarno wrote: >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. ACK. I did want to keep it around for a while for safety, and that period is clearly done. Thanks for your help with this! -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Bug#943798: ld.so: old Arm ABI detection patch causing problems, time to remove?
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
Bug#943798: ld.so: old Arm ABI detection patch causing problems, time to remove?
On Wed, Oct 30, 2019 at 12:17:20AM +, 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 Forgot to add: there's an llvm-objcopy patch under discussion here: https://reviews.llvm.org/D69188 -- Steve McIntyre, Cambridge, UK.st...@einval.com Is there anybody out there?
Bug#943798: ld.so: old Arm ABI detection patch causing problems, time to remove?
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? -- System Information: Debian Release: 10.1 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
