Bug 24289

Created attachment 11659 [details]
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.