[PATCH] D68101: [MC][ELF] Prevent globals with an explicit section from being mergeable

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers added a comment.

Just some more thoughts after being able to sleep on it.

The merge-able sections is generally handy for sections which I'm not specific about (in the added test case, the "implicit" sections).  For example, if I have global const data that I don't take the address of and has internal linkage, then rather it be in `.rodata`, it's handy for LLVM to suffix it into separate `.rodata.cst4`, `.rodata.cst8`, etc. sections that ARE merge-able and have uniform entity sizes.

But, if I explicitly state that I want something (code or data) in a specific section, it would be surprising to me if the compiler changed the section I explicitly specified to put that in anything other than what I specified, and that included adding suffixes (like `.cst4`, `.cst8`, etc).  Especially if I was manually performing relocations manually via libelf, or like the Linux kernel does.  If I put data in `.foo`, and try to look it up at runtime explicitly, I might be surprised if it was moved to `.foo.cst8`, for example.

If I'm explicitly putting code or data in explicit sections and actually care about those sections being merge-able, than I'd better also be proficient enough in linker scripts to explicitly merge those sections together myself.  Otherwise, I don't see GCC putting explicitly-sectioned data in merge-able sections, even with `-fmerge-all-constants` (which is already a dangerous flag to use) (GCC will put implicitly-sectioned data in merge-able if you specify `-fmerge-all-constants`, but that's not relevant for this patch which is about //explicitly-sectioned// code/data).


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

https://reviews.llvm.org/D68101