[Pkg-utopia-maintainers] Bug#876037: Bug#874585: dpkg-shlibdeps: does not parse Version References

[Matthias Klose]

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 <guillem at debian.org> 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.