On Thu, Feb 29, 2024 at 02:07:39PM -0700, Sam Edwards wrote:
On 2/28/24 04:15, Ilias Apalodimas wrote:
On Wed, 28 Feb 2024 at 13:11, Peter Robinson pbrobinson@gmail.com wrote:
On Wed, 28 Feb 2024 at 10:58, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
The arm linker scripts had a mix of symbols and C defined variables in an effort to emit relative references instead of absolute ones e.g [0]. This has led to confusion over the years, ending up with mixed section definitions. Some sections being defined with overlays and different definitions between v7 and v8 architectures. For example __efi_runtime_rel_start/end is defined as a linker symbol for armv8 and a C variable in armv7.
I am not sure if this used to be a compiler bug, but linker scripts nowadays can emit relative references, as long as the symbol definition is contained within the section definition. So let's switch most of the C defined variables
Should we be setting/upping the minimum version of the linker version as part of this?
The patch that added those as C-defined variables, was in 2013. So any linker that's not ancient history should emit those correctly.
GNU ld fixed the problem on 2016-02-23, with this entry in the bfd changelog:
- elflink.c (bfd_elf_record_link_assignment): Check for shared
library, instead of PIC, and don't check PDE when making linker assigned symbol dynamic.
It looks like the change was first included in binutils 2.27, released 2016-08-03. I don't know where the minimum linker version requirement is memorialized but there's a good chance that U-Boot already requires a version more recent than that. (Someone who knows where that is will have to check.)
In either case, I strongly agree: sections.c is an unnecessary workaround with any reasonably recent linker version, it's fickle/incompatible with non-GNU linkers such as LLD, and the marker symbols belong in the linker script. This patchset is a big step in the right direction!
We have the ld-version check logic same as the kernel but do not today enforce any minimum version. On ARM we only enforce gcc 6.0.0 being a minimum version, and that's likely too old too, in reality. So adding a check would be nice, but not required I think, given the age of the fix. Thanks for digging in to this!