This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Add STB_GNU_SECONDARY


On Fri, Apr 20, 2012 at 4:40 PM, Ian Lance Taylor <iant@google.com> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>
>> On Fri, Apr 20, 2012 at 3:59 PM, Ian Lance Taylor <iant@google.com> wrote:
>>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>>
>>>> On Fri, Apr 20, 2012 at 3:10 PM, Cary Coutant <ccoutant@google.com> wrote:
>>>>>> We only have very few bits to in STB_XXX field.
>>>>>
>>>>> This is exactly why I'm not in favor of this extension. The feature
>>>>> doesn't seem compelling enough to use up one of these precious
>>>>> reserved values (in fact, you're using the next-to-last one that's
>>>>> reserved for OS use).
>>>>>
>>>>> You want a backup definition? Put a weak def at the end of the link line.
>>>>>
>>>>
>>>> It doesn't work for us since the backup definition is
>>>> always used even if there is a normal definition in
>>>> a shared library or an archive.
>>>
>>> Can you expand on that? ?How can you refer to the backup definition if
>>> there is a normal definition?
>>>
>>
>> We need a definition for symbol, foo. ?Since we don't know if there
>> is a definition of foo at the final link time. ?We provide the backup
>> definition for foo. ?The backup one is ignored if there is a normal one in
>> an archive or DSO at link time.
>
> That use case would be satisfied by Cary's suggestion of adding a weak
> definition of the symbol in an object included at the end of the link
> line.

In our usage, the backup definition may not be at the end of
command line since it may reference library symbols.



-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]