This is the mail archive of the binutils@sourceware.org mailing list for the binutils 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: discarding rules for duplicate ELF comdat groups


>>> On 28.01.11 at 18:18, "H.J. Lu" <hjl.tools@gmail.com> wrote:
> On Fri, Jan 28, 2011 at 9:06 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>>> On 28.01.11 at 16:56, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>> On Fri, Jan 28, 2011 at 7:28 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>>>>> On 28.01.11 at 15:40, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>>>> On Fri, Jan 28, 2011 at 6:30 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>>>>>>> On 28.01.11 at 15:07, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>>>>>> On Fri, Jan 28, 2011 at 5:51 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>>>>>> It seems like currently the rule simply is to pick the first instance the
>>>>>>>> linker gets to see. Wouldn't it make sense to honor the group
>>>>>>>> signature's attributed (namely its binding), and prefer keeping an
>>>>>>>> instance with a global group signature over a weak or local one?
>>>>>>>> That would allow the programmer some control over which
>>>>>>>> instance to keep: My main motivation is to find a way to discard
>>>>>>>> the various weak fallback functions Linux has to cover cases where
>>>>>>>> e.g. some architectures implement certain functionality, while
>>>>>>>> others that don't can all use a generic implementation.
>>>>>>>>
>>>>>>>> I cannot see other mechanisms that would allow ld to discard
>>>>>>>> sections (not to speak of individual functions within sections).
>>>>>>>>
>>>>>>>
>>>>>>> Microsoft linker has some user controls over which comdat group
>>>>>>> instance to keep.  Will its scheme work for you?
>>>>>>
>>>>>> I'm not aware of any such controls - can you point me to
>>>>>> something describing this?
>>>>>
>>>>> /* COMDAT selection codes.  */
>>>>>
>>>>> #define IMAGE_COMDAT_SELECT_NODUPLICATES     (1) /* Warn if duplicates.  */
>>>>> #define IMAGE_COMDAT_SELECT_ANY              (2) /* No warning.  */
>>>>> #define IMAGE_COMDAT_SELECT_SAME_SIZE        (3) /* Warn if different size.
>>>>> */
>>>>> #define IMAGE_COMDAT_SELECT_EXACT_MATCH      (4) /* Warn if different.  */
>>>>> #define IMAGE_COMDAT_SELECT_ASSOCIATIVE      (5) /* Base on other section.
>>>>> */
>>>>
>>>> Oh, those you meant. No, they don't allow controlling which
>>>> instance will be retained.
>>>>
>>>
>>> You can always propose something.
>>
>> Which I think I did with my initial mail.
>>
> 
> Can you provide some examples?

While probably any of the __weak functions in Linux would be
good as example, just look at get_user_pages_fast() - it has a
__weak implementation in mm/util.c, and several arches
provide their own. It would be desirable to not keep the dead
general implementation around when overridden.

While for each individual function the amount of dead code
may be small, it sums up (and grows as new cases get added).

Jan


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