discarding rules for duplicate ELF comdat groups

discarding rules for duplicate ELF comdat groups

[Jan Beulich]

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).

Thanks, Jan

Re: discarding rules for duplicate ELF comdat groups

[H.J. Lu]

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?

-- 
H.J.

Re: discarding rules for duplicate ELF comdat groups

[Jan Beulich]

>>> 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?

Thanks, Jan

Re: discarding rules for duplicate ELF comdat groups

[H.J. Lu]

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.  */


-- 
H.J.

Re: discarding rules for duplicate ELF comdat groups

[Jan Beulich]

>>> 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.

Jan

Re: discarding rules for duplicate ELF comdat groups

[H.J. Lu]

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.


-- 
H.J.

Re: discarding rules for duplicate ELF comdat groups

[Jan Beulich]

>>> 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

Re: discarding rules for duplicate ELF comdat groups

[Ian Lance Taylor]

"Jan Beulich" <JBeulich@novell.com> writes:

> 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).

I think this idea should be raised on the generic-abi@googlegroups.com
mailing list.  http://groups.google.com/group/generic-abi .

Ian

discarding rules for duplicate ELF comdat groups

[Jan Beulich]

I had originally brought this up on the binutils mailing list, but it
was suggested to bring this up in this more generic forum:

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 attributes (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).

Thanks, Jan