This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] Always clear h->verinfo.verdef when overriding a dynamic definition
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Alan Modra <amodra at gmail dot com>, Nick Clifton <nickc at redhat dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Wed, 12 Sep 2018 08:00:36 -0700
- Subject: Re: [PATCH] Always clear h->verinfo.verdef when overriding a dynamic definition
- References: <20180809230914.GA8904@intel.com> <20180810030612.GF1544@bubble.grove.modra.org> <CAMe9rOodDP+KYaB=1NetuR700PUFnKraENWgdSXBtTuH9wz_BQ@mail.gmail.com> <20180810071508.GG1544@bubble.grove.modra.org> <CAMe9rOqzRVcoi_iRYGquyQqEMwEWfYdK2cbvE14FwaH1XTTQ5A@mail.gmail.com>
On Fri, Aug 10, 2018 at 12:23 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Aug 10, 2018 at 12:15 AM, Alan Modra <amodra@gmail.com> wrote:
>> On Thu, Aug 09, 2018 at 08:36:29PM -0700, H.J. Lu wrote:
>>> On Thu, Aug 9, 2018 at 8:06 PM, Alan Modra <amodra@gmail.com> wrote:
>>> > On Thu, Aug 09, 2018 at 04:09:14PM -0700, H.J. Lu wrote:
>>> >> When linker defines a symbol to override a definition, which came from
>>> >> a dynamic object before, we should always clear h->verinfo.verdef so
>>> >> that the symbol won't be associated with the version information from
>>> >> the dynamic object. This happened to the symbol "_edata" when creating
>>> >> an unversioned dynamic object linking against libQt5Core.so.5.11.1,
>>> >> which was created by gold, with 2 entries of "_edata@Qt_5" in its dynamic
>>> >> symbol table:
>>> >>
>>> >> 4822: 00000000004e36ed 0 NOTYPE GLOBAL DEFAULT 21 _edata@Qt_5
>>> >> 4823: 00000000004e36ed 0 NOTYPE GLOBAL DEFAULT 21 _edata@Qt_5
>>> >>
>>> >> Ld created the dynamic object with "_edata" in its dynamic symbol table
>>> >> which was linker defined and associated with the version information
>>> >> from libQt5Core.so.5.11.1.
>>> >
>>> > How did _edata come to have version info? A non-default versioned
>>> > _edata (with one '@') shouldn't make _edata defined. I think we
>>> > probably have another bug here to fix.
>>>
>>> That dynamic object is created against:
>>>
>>> /usr/lib64/libKF5ConfigCore.so.5.49.0
>>> /usr/lib64/libKF5CoreAddons.so.5.49.0 /usr/lib64/libKF5I18n.so.5.49.0
>>> /usr/lib64/libKF5DBusAddons.so.5.49.0 /usr/lib64/libQt5Xml.so.5.11.1
>>> /usr/lib64/libQt5DBus.so.5.11.1 /usr/lib64/libQt5Core.so.5.11.1
>>>
>>> Among them
>>>
>>> /usr/lib64/libQt5Xml.so.5.11.1
>>> 299: 000000000003e000 0 NOTYPE GLOBAL DEFAULT 18 _edata@@Qt_5
>>
>> Ah, so this would define _edata.
>>
>>> /usr/lib64/libQt5DBus.so.5.11.1
>>> 597: 0000000000092018 0 NOTYPE GLOBAL DEFAULT 18 _edata@@Qt_5
>>> /usr/lib64/libQt5Core.so.5.11.1
>>> 2292: 00000000004df640 0 NOTYPE GLOBAL DEFAULT 21 _edata@Qt_5
>>> 2293: 00000000004df640 0 NOTYPE GLOBAL DEFAULT 21 _edata@Qt_5
>>>
>>> The problem is triggered by the last 2 duplicated entries. The code
>>> in question was
>>> there when the binutils source was imported to sourceware.org. I
>>> couldn't think of
>>> a reason why it shouldn't clear h->verinfo.verdef when provide is TRUE.
>>
>> I too, but I was worried there was some way _edata@Qt_5 was defining
>> _edata. Patch OK but please do run the testsuite over lots of targets.
>>
>
> This is what I checked in after tested with many ELF targets.
>
Hi Nick,
Is that OK to backport:
https://sourceware.org/ml/binutils/2018-08/msg00242.html
https://sourceware.org/ml/binutils/2018-08/msg00398.html
to 2.31 branch?
--
H.J.