Re: RFC: Supporting multiple relocs per section

[Nick Clifton <nickc at redhat dot com>]

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? 

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