reassign 874585 src:binutils thanks On 17.09.2017 20:13, Guillem Jover wrote: > Control: tag -1 - moreinfo > Control: clone -1 -2 > Control: retitle -1 gcc-7: Discarded unused code leaves entry on > .gnu.version_r > Control: reassign -1 gcc-7 > Control: retitle -2 network-manager: Unused code causes gcc to leave unused > version reference > Control: reassign -2 network-manager > > Hi! > > On Sun, 2017-09-10 at 22:12:13 +0100, Dimitri John Ledkov wrote: >> On 10 September 2017 at 15:03, Guillem Jover <[email protected]> wrote: >>> On Thu, 2017-09-07 at 16:16:49 +0100, Dimitri John Ledkov wrote: >>>> Package: dpkg >>>> Version: 1.18.24 >>>> Severity: important >>> >>>> I am attaching the objdump to this bug report. In that log, one can >>>> see that the highest symbol referenced by Dynamic symbol table is for >>>> GLIBC_2.17 which is the dependency dpkg-shlibs generates. >>>> >>>> However, in the `Version References' section, one can see that >>>> GLIBC_2.25 is required. >>>> >>>> The net result is that libc6 (>= 2.17) is generated, instead of the >>>> required libc6 (>= 2.25). >>>> >>>> The binaries are not executable when e.g. 2.24 glibc is installed and >>>> fail like so: >>>> >>>> # ldd /usr/sbin/NetworkManager >>>> /usr/sbin/NetworkManager: /lib/x86_64-linux-gnu/libc.so.6: version >>>> `GLIBC_2.25' not found (required by /usr/sbin/NetworkManager) >>>> >>>> I am not sure how glibc managed to generate a Version reference, >>>> without using any of the dynamic symbols from 2.25. >>> >>> I've built and checked the resulting binary, by objdump'ing everything >>> I could think of, and I was unable to see why the version reference >>> had been picked up. >>> >>>> Reading the code, it seems like maybe dpkg-shlibdeps needs to grow the >>>> ability to parse "Version References" section of the objdump and use >>>> version symbols referenced there to bump up requirements just like >>>> dynamic symbols do? >>> >>> Before doing that I'd like to first understand why that is the case, if >>> it's expected and not a bug in the toolchain or similar. >> >> That is a very reasonable question. Given that the version dep is 2.25 >> I went through the glibc abi lists to see what was new in 2.25. >> A few things from those are referenced in the NetworkManager but >> unused (e.g. makedev()) and thus did not gain a dep (e.g dropping that >> function did not result in getting the ABI back lower). >> However, in the partial embedded copy of systemd there is embeded >> implementation of explicit_bzero if glibc does not provide one. >> It seems that NetworkManager included the declaration check too in >> their configure.ac such that with glibc 2.25+ explicit_bzero from libc >> starts to be referenced. >> However, in the end, none of the bits that NetworkManager actual use >> hit the string_erase function and thus do not call explicit_bzero. >> Thus it looks like compiler did compile / link usage of >> explicit_bzero, and eventually dropped it, yet version info persistent >> to the end binaries/libraries. >> With the attached patch, builds of network-manager end up not having >> GLIBC_2.25 version reference. > > Thanks for the investigation! When I also checked the new symbols in > glibc, I also suspected that explicit_bzero was a very probable > candidate, but it was not obvious why, simply from the glibc side. > >> Is this normal toolchain behaviour to not optimise out version >> references, when all symbols are optimised out? >> The code is crazy, but I would have expected optimised out things to >> remove version references too. > > Yes, that looks like a bug to me, if the code gets removed then the > versioned references should also be removed, otherwise we are > unnecessarily demanded a version that is greater than it's really needed. > > Reassigning both to gcc-7 to get this fixed there (assuming this is > not a binutils problem?), and to network-manager to workaround the > issue for now. > > I'm not sure if gcc-6 is affected, if it is, please clone another one > into that.
no, it's a binutils issue, and some network-manager crazyness ... it defines a backup for the explicit_bzero function which is new in glibc 2.25, but it fails to define that for __explicit_bzero_chk which is used when building with -D_FORTIFY_SOURCE. So either it should define two versions of this function, or discard it at all, because it's not used.
