https://sourceware.org/bugzilla/show_bug.cgi?id=24289
Bug ID: 24289
Summary: MEMORY regions can no longer use LENGTH and ORIGIN
(2.32 regression).
Product: binutils
Version: 2.32
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: nbowler at draconx dot ca
Target Milestone: ---
Created attachment 11659
--> https://sourceware.org/bugzilla/attachment.cgi?id=11659&action=edit
Possible fix
Consider the following linker script:
% cat >test.ld <<'EOF'
MEMORY {
a : ORIGIN = 0, LENGTH = 16M
b : ORIGIN = ORIGIN(a) + LENGTH(a), LENGTH = 16M
}
SECTIONS {
ENTRY(entry)
.text 1M : { *(.text*) } >a
}
a_start = ORIGIN(a);
a_end = ORIGIN(a) + LENGTH(a);
b_start = ORIGIN(b);
b_end = ORIGIN(b) + LENGTH(b);
EOF
This works as exepcted with ld-2.31: the codestart symbol gets the value 0 and
the datastart symbol gets the value 16777216. However, 2.32 appears to reject
the LENGTH(code) use in the MEMORY block:
% ld --version
GNU ld (GNU Binutils) 2.32.0.20190301
[...]
% ld -Ttest.ld test.o
ld: invalid origin for memory region b
This appears to be caused by the fix for PR23648 (which I reported...),
but for some reason I didn't notice this particular problem until now :(
Anyway the issue seems to be that when evaluating the expressions, ORIGIN and
LENGTH explicitly don't get processed when the phase is lang_first_phase_enum,
and that patch which moved lang_do_memory_regions moved the evaluation of
memory regions into this phase.
Simply removing the phase check for ORIGIN and LENGTH evaluation seems to
fix this problem with no test regressions.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
