[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug ld/25081] Discrepancy between VMA and LMA after ALIGN
From: |
tnfchris at sourceware dot org |
Subject: |
[Bug ld/25081] Discrepancy between VMA and LMA after ALIGN |
Date: |
Wed, 09 Oct 2019 11:05:39 +0000 |
https://sourceware.org/bugzilla/show_bug.cgi?id=25081
Tamar Christina <tnfchris at sourceware dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tnfchris at sourceware dot org
--- Comment #1 from Tamar Christina <tnfchris at sourceware dot org> ---
Ah I see Alan has already claimed it,
if it helps I've bisected it to
commit 14ea2c1b230a62f312346fb16716b3dd4850815b
Author: Andrew Burgess <address@hidden>
Date: Tue Jan 17 19:13:29 2017 +0000
ld: Track changes to default region LMA even for empty sections
Given a linker script fragment like this:
SECTIONS {
. = 0x1000;
.text : AT(0x100) { *(.text) }
.data : AT(0x200) { *(.data) }
.rodata : AT(0x300) { *(.rodata) }
}
and an input file containing sections, '.text', '.data.1', and
'.rodata', then we'd expect the linker to place '.text' and '.rodata' in
the obvious way, and the '.data.1' orphan section would be located after
the '.data' section (assuming similar section properties).
Further, I believe that the expectation would be that the LMA for the
orphan '.data.1' section would start from 0x200 (as there is no '.data'
content).
However, right now, the LMA for '.data.1' would be 0x101, following on
from the '.text' section, this is because the change in LMA for the
'.data' section is not noticed by the linker, if there's no content in
the '.data' section.
What can be even more confusing to a user (though the cause is obvious
once you understand what's going on) is that adding some content to
'.data' will cause the orphan '.data.1' to switch to an LMA based off of
0x200.
This commit changes the behaviour so that an empty section that is in
the default lma region, and sets its lma, will adjust the lma of the
default region, this change will then be reflected in following sections
within the default lma memory region.
There's a new test to cover this issue that passes on a range of
targets, however, some targets generate additional sections, or have
stricter memory region size requirements that make it harder to come
up with a generic pass pattern, that still tests the required
features. For now I've set the test to ignore these targets.
ld/ChangeLog:
* ldlang.c (lang_size_sections_1): Shortcut loop only after
tracking changes to the default regions LMA.
* testsuite/ld-elf/orphan-9.ld: Extend header comment.
* testsuite/ld-elf/orphan-10.d: New file.
* testsuite/ld-elf/orphan-10.s: New file.
* NEWS: Mention change in behaviour.
--
You are receiving this mail because:
You are on the CC list for the bug.
- [Bug ld/25081] New: Discrepancy between VMA and LMA after ALIGN, joey.ye at arm dot com, 2019/10/08
- [Bug ld/25081] Discrepancy between VMA and LMA after ALIGN, amodra at gmail dot com, 2019/10/09
- [Bug ld/25081] Discrepancy between VMA and LMA after ALIGN,
tnfchris at sourceware dot org <=
- [Bug ld/25081] Discrepancy between VMA and LMA after ALIGN, cvs-commit at gcc dot gnu.org, 2019/10/09
- [Bug ld/25081] Discrepancy between VMA and LMA after ALIGN, amodra at gmail dot com, 2019/10/09
- [Bug ld/25081] Discrepancy between VMA and LMA after ALIGN, joey.ye at arm dot com, 2019/10/09
- [Bug ld/25081] Discrepancy between VMA and LMA after ALIGN, cvs-commit at gcc dot gnu.org, 2019/10/10