Re: RFC: Supporting multiple relocs per section

[Alan Modra <amodra at gmail dot com>]

On Fri, Feb 14, 2020 at 10:30:47AM +0000, Nick Clifton wrote:
>   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, so I also added a
>   hook to allow backends to override this behaviour if they so desire.

That sounds like a bug that should be fixed for all ELF targets and
not via a target hook.  Note how we shift section indices in the
reserved range from 0xff00..0xfffe to 0xffffff00..0xfffffffe in
elf_swap_symbol_in.  There may well be some target specific work
involved but likely only in targets that want the linker to create
such symbols.  Separate patch anyway, please.

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

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?  And I suppose there isn't any
way to convince people not to objcopy/strip files with extra reloc
sections?  What about requiring those extra reloc sections only have
relocs using a zero symbol index?

-- 
Alan Modra
Australia Development Lab, IBM