[PATCH] D29453: [ELF] - Allow going over alignment commands in algorithm of placing non-alloc orphans.

[George Rimar via Phabricator via llvm-commits]

grimar added a comment.

In https://reviews.llvm.org/D29453#665381, @ruiu wrote:

> I spent a fair amount of time to try to understand this, but this still looks really odd. My understanding is that, adding non-SHF_ALLOC sections doesn't change the current virtual address pointer (the '.' special variable), because non-allocatable sections are not mapped to the memory at runtime.


It actually changes it, explanation below.

> IIUC, what you wrote is `ASSERT(_end <= 0x8000)` in http://lxr.free-electrons.com/source/arch/x86/boot/setup.ld fails with LLD because LLD adds non-alloc sections after `.bss` but before `_end` symbol. But that's odd, because adding non-alloc sections shouldn't increment `.` variable.
> 
> What am I missing here? I would really appreciate if you describe it without too much examples, but why you think what you are doing is semantically correct.

I will try :) Little single sample:

If we have a script with _end after all allocatable sections and _end2 after single non-allocatable:

  SECTIONS { .text : { *(.text*) }   _end = .;    .nonalloc: { *(.nonalloc*) }    _end2 = .;  }

You assume that non-alloc should not increment counter. But both BFD/gold output would be next:

  [ 1] .text             PROGBITS         0000000000000000  00001000
       0000000000000001  0000000000000000  AX       0     0     4
  [ 2] .nonalloc         PROGBITS         0000000000000000  00001001
       0000000000000008  0000000000000000           0     0     1
  
     5: 0000000000000009     0 NOTYPE  GLOBAL DEFAULT    1 _end2
     6: 0000000000000001     0 NOTYPE  GLOBAL DEFAULT    1 _end

Symbols has different values, dot variable is a location counter, it is not the same as VA, though behaves close. 
Non-alloc sections affect it value too. 
And we already did that (naturally , I believe). I see no reasons why we should try to 
behave in different way than gnu linkers here ?


https://reviews.llvm.org/D29453