[PATCH] D50688: [LLD] Warn if non-alloc sections occur before alloc sections in linker scripts

ben via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Aug 20 17:55:55 PDT 2018


bd1976llvm added a comment.

Hi. Sorry to be slow to comment on this.

This seems related to https://reviews.llvm.org/D34204 (Allow non-alloc sections to be assigned to segments). You will need to follow the email thread as most of the comments were not on the phabricator review.

I find the gnu linker script docs difficult to read in this area. In some places they use the term segment as an alias for program header. In other places segment seems to indicate a region of process address space. The docs state that certain segments are "segments of memory which the system loader will load from the file" and only SHF_ALLOC sections contribute to these segments. However it does not state which segments these are - apart from that loadable segments (PT_LOAD) are included in the set. This limitation means that you can't define custom PHDR types that are treated as "segments of memory which the system loader will load from the file".

I believe that linker scripts are older than elf and therefore the two do not always fit nicely together. Mixing alloc and non-alloc sections in a PT_LOAD is one of those things that makes sense in linker scripts but not in ELF. Another example is that Linker scripts allow you combine sections by name (ignoring section flags).

I would like to see the simplest approach here. To me the simplest approach is that linker scripts ideally should be as explicit as possible. For example, if you have a linker script that assigns a set of sections to a PHDR:

PHDRS {my_phdr PT_LOAD FLAGS(0x4);}
SECTIONS { .mine : { *(.mine) } : my_phdr }

Then the linker should simply concatenate any matching input sections and assign them to the specified PHDR. This should override any flags of the input sections including SHF_ALLOC. In my opinion it is very confusing to change the behavior of the above script based on whether the input sections are SHF_ALLOC or not. Warning or erroring if any of the input sections were non-shf-alloc would catch any mistakes.

This simple approach is a difference in behavior vs the gnu linkers, but quite possibly there are no real links that would be broken by this difference in behavior as, anecdotally, I think that mixing SHF_ALLOC and non-SHF_ALLOC sections is rare and use of the PHDRS command is also rare.

Wrapping up I suppose the important thing is to see how hard it would be to keep the current easy to understand linker script placement behavior and to fix https://bugs.llvm.org/show_bug.cgi?id=37607 by adjusting PHDR creation to create the appropriate PHDRs for that testcase. If that is easy to do then that would be more appealing to me.


Repository:
  rLLD LLVM Linker

https://reviews.llvm.org/D50688





More information about the llvm-commits mailing list