[PATCH] D17269: [ELF] - Implemented linkerscript sections padding.

[George Rimar via llvm-commits]

grimar added inline comments.

================
Comment at: ELF/LinkerScript.h:42
@@ +41,3 @@
+  StringRef Name;
+  llvm::support::ubig32_t Filler = (llvm::support::ubig32_t)0;
+};
----------------
ruiu wrote:
> I realized that I didn't actually understand what you said until now (because my approach should work and memcpy is the right way to copy filler to the section). You seems to misunderstand the feature.
> 
> If a filler is of the form 0x<hex digits>, then it is an arbitrary long sequence of hex digits. It is not a four byte value.
> 
> So this type needs to be std::vector<uint8_t>.
Let me try to explain again then. Consider the next script and code:

```
SECTIONS {
 .mysec : { *(.mysec*) } =0x11223344 
}
```

```
.section        .mysec.1,"a"
.align  4
.byte   0x66

.section        .mysec.2,"a"
.align  4
.byte   0x66

.globl _start
_start:
 nop
```

Output from my initial implementation would be: 0x66 0x11 0x22 0x33 0x66. What is equal to gold and bytes are used correctly (in growing order, started from first for each 'hole' heeds filling).

Output from your approach is: 0x66 0x22 0x33 0x44 0x66. So bytes are shifted what makes no sence in using bytes at all, since result is unexpected.

>> So this type needs to be std::vector<uint8_t>.
Agree here, just checked gold, it allows any length filler it seems:

```
SECTIONS
{
  . = 0x08048000 + SIZEOF_HEADERS;
  .mysec        : { *(.mysec*) } =0x11223344556677889911223344
}
```


http://reviews.llvm.org/D17269