[PATCH] D74741: [ELF] Warn changed output section address

[Fangrui Song via Phabricator via llvm-commits]

MaskRay marked an inline comment as done.
MaskRay added inline comments.


================
Comment at: lld/test/ELF/linkerscript/lma-align.test:8
 
+# WARN: warning: start of section .data changes from 0x11001 to 0x11010
+# WARN: warning: start of section .bss changes from 0x11021 to 0x11040
----------------
psmith wrote:
> While the warnings look correct from the LLD last known update perspective, are they what a user would want to see? Looking at the script:
> 
> - As a user I set the address of .data to 0x11000, why is LLD reporting 0x11001? Perhaps it is worth reporting the value of the original addrexpr.
> - Although "." is an addrexpr it is no different to not using an addrexpr. Could we consider addrexpr involving "." as relative to previous dot expressions and not warn? I'm not 100% behind not warning as there could be a context like . = 0x10000 ; before the addrexpr involving "." although I expect that is rare.
> 
> ```
> SECTIONS {
>   .text 0x1000 : { *(.text*) } >ROM
>   ## Input section alignment decides output section alignment.
>   .data.rel.ro 0x11000 : { *(.data.rel.ro) } >RAM AT>ROM
>   ## ALIGN decides output section alignment.
>   .data . : ALIGN(16) { *(.data*) } >RAM AT>ROM
>   ## Start a new PT_LOAD because the LMA region is different from the previous one.
>   .bss . : ALIGN(64) { *(.bss*) } >RAM
> }
> ```
This warning is reported only when `addrExpr` is set (`.`, not `ALIGN(16)`).

section-align2.test has a case where `addrExpr` is set while `alignExpr` is not:

`.data2 . : { *(.data2) }`

> As a user I set the address of .data to 0x11000, why is LLD reporting 0x11001? Perhaps it is worth reporting the value of the original addrexpr.

When lld tries to layout `.data`, dot is 0x11001.

For comparison, GNU ld reports `ld.bfd: warning: changing start of section .data2 by 7 bytes`


I believe this patch matches GNU ld behavior: warn if the actual address is not equal to `addrExpr`. This can be caused by either `ALIGN` or input section alignments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74741