[PATCH] D75724: [ELF] Simplify sh_addr computation and warn if sh_addr is not a multiple of sh_addralign

Roland McGrath via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 10 11:25:28 PDT 2020


mcgrathr added a comment.

I wholeheartedly endorse documenting the policy on linker script semantics.  I think the described deviation from GNU semantics for cases where explicit output section alignment doesn't jibe with input section alignment is generally fine.  That is, I think this corner case is best avoided and I'm not too concerned with exactly how it goes when it happens.  The warning for the case of an explicit address that is misaligned wrt input section sh_addralign is the most important thing for avoiding accidents.  For the explicit alignment being less than than input requirements, the lld behavior of using the maximum of the two seems sensible to me (essentially the explicit alignment in the linker script is just another of the requirements like all the inputs' sh_addralign values and you align to the maximum of the whole set, which is perfectly intuitive).  If anything, I think the GNU linkers should warn about violating input sh_addralign requirements if they're going to have that behavior.

In my case, the change in behavior for the explicit alignment < input alignment case revealed a bug in my code producing the input sections and showed me that I really wanted to reorganize my linker script so it was testing the input section alignment with asserts rather than controlling it explicitly in the output section.  So if anything that suggests warning for any instance of an explicit alignment not matching up with input requirements.  But it seems likely that the most common use of explicit alignments is exactly when setting the minimum alignment of the output section is the intent and that being increased by input sh_addralign requirements is normal and expected, and not a case like mine.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75724/new/

https://reviews.llvm.org/D75724





More information about the llvm-commits mailing list