[PATCH] D150637: [lld][ELF] Add option for suppressing section type mismatch warnings

[Leonard Chan via Phabricator via llvm-commits]

leonardchan added a comment.

In D150637#4345199 <https://reviews.llvm.org/D150637#4345199>, @peter.smith wrote:

> Apologies for the long answer. The TL;DR is that I'd prefer we not give the warning at all for NOLOAD as that is what it is designed to do, and working around the warning can be awkward for people not familiar with linkers.
>
> We have been seeing similar problems within Arm with some of our open source projects Thanks for bringing this up. In all of these cases the projects wanted to work with both GNU and LLVM toolchains and at least one of them would not turn off fatal warnings.
>
> I had been working on a patch for this area myself during some down time at Euro LLVM. My suggestion was to:
>
> - Record the intention to use NOLOAD (currently I don't think we can tell the difference between `OutputSection <address> TYPE = SHT_NOBITS : { ... }` and `OutputSection <address> (NOLOAD)`.
> - Do not warn at all for `NOLOAD` as changing section type is what it is designed to do (see below). Make the mismatch between `SHT_NOBITS` an error.
>
> Another thought I had was to read the contents of the section, only warn if the contents of the section are non-zero. This would handle the most common source of these warnings (small memory mapped peripherals).
>
> As I understand it NOLOAD is used for two purposes. The first is memory mapped peripherals in C. An example:
>
>   // C code, by convention .gicd is SHT_PROGBITS even though it is 0.
>   GICv3_distributor __attribute__((section(".gicd"))) gicd;
>   
>   // linker script, place section
>    .gicd 0x2f000000 (NOLOAD): { *(.gicd) }
>
> Which provokes:
>
>   ld.lld: warning: section type mismatch for .gicd
>   >>> obj/GICv3_gicd.o:(.gicd): SHT_PROGBITS
>   >>> output section .gicd: SHT_NOBITS
>
> This can sometimes be worked around by using the naming convention of `.bss.` prefix `__attribute__((section(".bss.gicd")))` which does produce a `SHT_NOBITS` section. However the `.bss.` prefix means that any linker script with
>
>   .bss : { *(.bss .bss.*) } 
>
> will match `.bss.gicd` before it gets to `.gicd 0x2f000000 (NOLOAD): { *(.gicd) }`
>
> So this can be made to work, but it is error prone, and difficult for a user trying to transition from GNU ld as the match is easy to miss.

+1 for the non-zero check. A lot of the cases I've seen fall under this and this could also be an alternative approach to https://github.com/llvm/llvm-project/issues/62690.

> The second use for NOLOAD is not something I've seen in person (https://stackoverflow.com/questions/57181652/understanding-linker-script-noload-sections-in-embedded-software) . My understanding is that it is used when parts of an embedded system are built separately. For example assume that there is a ROM kernel with entry points available at a specific address. This ROM is already on the device so we don't want it in the ELF file but we do want access to its symbols and we don't want to use any of its addresses. In this case we can use NOLOAD for the ROM which permits the program to link against the addresses but not be part of the program. Something like:
>
>   ROM 0x0 (NOLOAD) : { rom_*.o (.text) ... }
>   /* Rest of program */
>   FLASH 0x10000 : { *(.text) ... }
>
> I think relinking all the objects with NOLOAD is more error prone than just linking against a list of symbol entry points, which I think is the more common approach.
>
> To summarise:
>
> - I would prefer we not put out the warning with NOLOAD as default as I think it is working as designed.
> - An option to suppress/enable the warning is a good second choice. I'd prefer us to suppress by default, particularly for NOLOAD.

I'd also be fine with keeping the warning suppression but having it off by default.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D150637