[lld] [LLD][ELF] Support 'i' and 'l' memory region attributes (PR #110937)

[Peter Smith via llvm-commits]

smithp35 wrote:

As I understand it, the use of `i` or `l` permits someone to filter out BSS from non-BSS in the MEMORY commands. If you don't need to do that then the existing flags work better.

One possible reason that I can think of to do that could be for memory mapped peripherals early in the address space, that we don't want to get output sections "default assigned" to.

An example from a recent internal project that uses `w` for the memory mapped peripherals :
```
MEMORY
{
  PL011 (w) : ORIGIN = 0x1c090000, LENGTH = 0x10000
  GICD  (w) : ORIGIN = 0x2f000000, LENGTH = 0x10000
  GICR (rw) : ORIGIN = 0x2f100000, LENGTH = 0x100000
  FLASH (rx)  : ORIGIN = __ROM_BASE, LENGTH = __ROM_SIZE
  RAM   (rwx) : ORIGIN = __RAM_BASE, LENGTH = __RAM_SIZE
}
```
The peripherals PL011 and GICD could have used `!i` to prevent any default assignment (OutputSections with no assignment of memory region) of data sections to them.

I guess the misuse you are thinking of is separating SHT_NOBITS from SHT_PROGBITS so that it can't be represented by a single program header, or placing SHT_NOBITS before SHT_PROGBITS so that it has to be written to the file anyway? At least in the former case I'm not too worried as embedded systems will not load from the ELF file directly anyway.

I haven't personally seen `i` or `l` in a linker script, possibly because it isn't particularly well documented, all it says I'd is `initialized section` without defining what that means. Unfortunately `MEMORY` and its flags aren't easy to search for. Perhaps it could be useful to share links to use cases assuming they are public.

Personally, while niche, I think we could make the case for including `i` and `l` on the grounds of compatibility, even if the use cases are small as I don't think the misuse is particularly likely based on the available documentation.

https://github.com/llvm/llvm-project/pull/110937