RFC: Supporting multiple relocs per section

[Fangrui Song]

Hi Nick,

On 2020-02-19, Nick Clifton wrote:
>Hi Alan,
>
>>>   As part of this process I also discovered that the BFD library would
>>>   unconditionally convert OS-specific and PROC-specific section indices
>>>   into SHN_ABS indices when writing out symbol tables,
>
>> That sounds like a bug that should be fixed for all ELF targets and
>> not via a target hook.
>
>A good point - I will do that.
>
>
>
>>> [1] This is to support kernel live patch modules used by Fedora and RHEL
>>>   and possibly other distributions too.
>>
>> Can the need for multiple reloc sections be avoided?  Or at least
>> any processing on extra reloc sections?

(I wanted to ask the same question...)

>Not now.  The scheme has been in place for a couple of years now, so
>I think that it is too late to change it.

>> The current support as such
>> for multiple reloc sections in bfd is by treating any extra reloc
>> sections as normal sections, ie. just a blob of data in the section.
>> Or@least that is what is supposed to happen.
>
>I thought so too, but it turns out not to be so.  The extra reloc
>sections are dropped, rather than being preserved in transit from
>input to output.
>
>> Hmm, I see your patch updates reloc symbols in the extra reloc
>> sections.  Am I correct in guessing that the underlying problem is
>> that objcopy/strip renumber symbols?
>
>Yup. :-)
>
>>  And I suppose there isn't any
>> way to convince people not to objcopy/strip files with extra reloc
>> sections?
>
>No.  The actual issue came about because the kernel team are trying to
>update their practices and rather than create and distribute these
>live update modules by hand they are now trying to use the brew/koji
>build systems.  Which use objcopy and strip from the binutils.  Which
>corrupts the modules...
>
>> What about requiring those extra reloc sections only have
>> relocs using a zero symbol index?
>
>No, they need specific symbol indicies in order for the relocations
>to be applied by the kernel's live patcher...
>
>Cheers
>  Nick

Where can we find more information about the kernel side implementation,
if it is open?