section with start address causes lld to expand the previous region incorrectly

[Quuxplusone]

Bugzilla Link	PR38624
Status	NEW
Importance	P normal
Reported by	Dan Callaghan (djc@djc.id.au)
Reported on	2018-08-17 23:07:54 -0700
Last modified on	2018-08-21 07:39:02 -0700
Version	unspecified
Hardware	All All
CC	grimar@accesssoftek.com, llvm-bugs@lists.llvm.org
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

Say you are linking for an embedded target, with two disjoint memory regions
FLASH and RAM. If you declare a section with a specific start address in a new
memory region, lld incorrectly tries to expand the *previous* section's memory
region to reach the specified address.

Here is a reproducer, using lld 7.0.0rc1:

$ cat test.c
void _start(void) {
}
$ gcc -nostdlib -nostartfiles -c test.c
$ cat link.x
MEMORY
{
  FLASH : ORIGIN = 0x20400000, LENGTH = 512M
  RAM : ORIGIN = 0x80000000, LENGTH = 16K
}
SECTIONS
{
  .text :
  {
    *(.text);
  } > FLASH

  .rodata :
  {
    *(.rodata);
  } > FLASH

  PROVIDE(_sbss = ORIGIN(RAM));
  .bss _sbss :
  {
    *(.bss);
  } > RAM

  .data : AT(LOADADDR(.rodata) + SIZEOF(.rodata))
  {
    *(.data);
  } > RAM

  /DISCARD/ :
  {
    *(.eh_frame);
  }
}
$ lld -flavor gnu -Tlink.x -o test test.o
lld: error: section '.text' will not fit in region 'FLASH': overflowed by
1069547520 bytes

The problematic part is here:

  PROVIDE(_sbss = ORIGIN(RAM));
  .bss _sbss :
  {

where it specifies the _sbss symbol as the start address for .bss. Lld is
trying to expand the FLASH region up to reach this address, but it's wrong
because .bss is going into the RAM region not FLASH. It fails because FLASH is
not large enough.

If you remove the start address for .bss, namely:

  .bss :
  {

then it links successfully and you get the expected result (.bss is placed at
the beginning of the RAM region, and everything fits normally).

[Quuxplusone]

We have a patch on a review that fixes how LLD works with regions.
I guess it might fix this, though I did not check.

(https://reviews.llvm.org/D50494)

[Quuxplusone]

I tried with the diff from https://reviews.llvm.org/D50494 applied and the problem still exists.

[Quuxplusone]

(In reply to Dan Callaghan from comment #2)
> I tried with the diff from https://reviews.llvm.org/D50494 applied and the
> problem still exists.

Ok, thanks for the info, Dan!

[Quuxplusone]

D50494 claims this is now fixed.