stephanosio
commented
1 year ago The problem is that the BFD program header rewrite implementation makes a questionable assumption that the LMA of a segment will be aligned to the alignment of the first section in the segment:
/* If the first section in a segment does not start at
the beginning of the segment, then something is
wrong. */
if (align_power (map->p_paddr
+ (map->includes_filehdr
? iehdr->e_ehsize : 0)
+ (map->includes_phdrs
? iehdr->e_phnum * iehdr->e_phentsize
: 0),
output_section->alignment_power * opb)
!= output_section->lma * opb)
goto sorry;This is not a problem when the LMA is equal to the VMA and both are aligned at the section alignment; but, for the sections that have different VMA and LMA, only the VMA is guaranteed to be aligned at the section alignment and the LMA may or may not be aligned at the same boundary.
Now looking at the cases with next_event_cyc = new_next_event_cyc; (bad) and without (good).
Good:
Program Header:
[...]
LOAD off 0x00005044 vaddr 0x20000000 paddr 0x00010f64 align 2**2
filesz 0x000000b8 memsz 0x000000b8 flags rw-
[...]
Sections:
Idx Name Size VMA LMA File off Algn
[...]
10 datas 000000b0 20000000 00010f64 00005044 2**2
CONTENTS, ALLOC, LOAD, DATA
[...]Bad:
Program Header:
[...]
LOAD off 0x00005098 vaddr 0x20000000 paddr 0x00010fb4 align 2**3
filesz 0x000000c0 memsz 0x000000c0 flags rw-
[...]
Sections:
Idx Name Size VMA LMA File off Algn
[...]
10 datas 000000b8 20000000 00010fb4 00005098 2**3
CONTENTS, ALLOC, LOAD, DATA
[...](the full dump can be found in https://gist.github.com/stephanosio/5946bd6f8f249b5329fb4982f87cd58e)
Note that, for both good and bad, the datas section is the first section in a segment.
For good, the LMA is 0x10f64 which is aligned at 2**2.
For bad, the LMA is 0x10fb4 which is NOT aligned at 2**3.
As seen above, the BFD implementation expects the LMA of a segment to be aligned at the alignment of the first section of the segment, and attempts to align the address of the segment LMA to the alignment of the first section before comparing it to the actual LMA of the first section for the purpose of verifying that the first section starts at the beginning of the segment.
When running objcopy --change-section-lma *+483328 ..., which offsets the LMA by 0x76000:
In case of good, since the segment LMA is divisible by 4 (2**2), this results in 0x86f64 == 0x86f64, which evaluates to true.
In case of bad, since the segment LMA is NOT divisible by 8 (2**3), this results in 0x86fb8 == 0x86fb4, which evaluates to false.
Since the align_power() is applied on the segment LMA mainly for the purpose of handling the alignment in case there are file or program headers in the segment (the expectation is that, if there are file and program headers in a segment, then the linker would have respected the section alignment for the first section), adding an alternate check without the segment LMA alignment for the header-less case would make sense to support the VMA != LMA case.
diff --git a/bfd/elf.c b/bfd/elf.c
index 79f71aa81e2..a0b65c4fd3b 100644
--- a/bfd/elf.c
+++ b/bfd/elf.c
@@ -7412,7 +7412,7 @@ rewrite_elf_program_header (bfd *ibfd, bfd *obfd, bfd_vma maxpagesize)
/* If the first section in a segment does not start at
the beginning of the segment, then something is
wrong. */
- if (align_power (map->p_paddr
+ if ((align_power (map->p_paddr
+ (map->includes_filehdr
? iehdr->e_ehsize : 0)
+ (map->includes_phdrs
@@ -7420,6 +7420,7 @@ rewrite_elf_program_header (bfd *ibfd, bfd *obfd, bfd_vma maxpagesize)
: 0),
output_section->alignment_power * opb)
!= output_section->lma * opb)
+ && (map->p_paddr != output_section->lma * opb))
goto sorry;
}
else
github-actions[bot]
ghost
gmarull
nordicjm
danieldegrasse
Describe the bug
I discovered a heisenbug while adding this new feature to Zephyr: https://github.com/zephyrproject-rtos/zephyr/pull/57229. Some failures with objcopy occur when using
CONFIG_BUILD_OUTPUT_ADJUST_LMA, e.g. when compiling some MCUboot tests.To Reproduce
Use https://github.com/zephyrproject-rtos/zephyr/pull/57229 branch and build:
If the following patch is applied to the branch, the problem disappears:
Expected behavior Build succeeds
Impact Blocker
Logs and console output
Environment (please complete the following information):
Additional context N/A