[0/4] LD: Support fixed-size sections some psABIs may require

Message ID alpine.DEB.2.00.1801302217320.4074@tp.orcam.me.uk
Headers show
Series
  • LD: Support fixed-size sections some psABIs may require
Related show

Message

Maciej W. Rozycki Jan. 31, 2018, 10:56 p.m.
Hi,

 Following commit 58807c48a5a3 ("_bfd_mips_elf_final_link: Notify user 
about wrong .reginfo size") I have decided to look into the issue again 
and concluded that a better way to handle non-standard `.reginfo' (and 
also `.MIPS.abiflags') section sizes will be to actually permit them and 
then either truncate or pad out the resulting output section to the psABI 
mandated size, giving people more flexibility in handling those sections.

 While implementing that I realised the actual cause of the original issue 
of the assertion failure triggering in `_bfd_mips_elf_final_link' was 
generic linker relaxation code, which resets the output section size set 
by the MIPS backend in `_bfd_mips_elf_always_size_sections', the handler 
for the `bed->elf_backend_always_size_sections' backend method, as this is 
called too early.  But then it does appear to be the right place to do it.
So to address that I invented a new SEC_FIXED_SIZE section flag, which is 
never set by generic code, but backends can use it to mark special psABI
sections whose size has to remain unchanged.  I imagine there might be 
other targets beyond the MIPS one who may have a use for it.

 As there are no bits left for a new section flag I have to remove one 
first, choosing one which has been unused since 2003, making this 
submission a small patch series.  The second change is actual support for 
the SEC_FIXED_SIZE flag in the generic linker.  The third is the MIPS 
backend part to use it along with a number of test cases.  Finally the 
fourth change reverts the commit referred above as then the original 
assertion can be placed back as the SEC_FIXED_SIZE arrangement is meant to 
guarantee the size will be fixed at that point, as verified by the test 
cases included with the second part.

 See the descriptions of individual patches for additional details.

  Maciej