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

[Rui Ueyama via llvm-commits]

ruiu added inline comments.

================
Comment at: ELF/LinkerScript.h:42
@@ +41,3 @@
+  StringRef Name;
+  llvm::support::ubig32_t Filler = (llvm::support::ubig32_t)0;
+};
----------------
grimar wrote:
> 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
> }
> ```
I think I completely understand your point, and still I prefer my approach.

Speaking of Filler's type, can you change the type to std::vector<uint8_t>?


http://reviews.llvm.org/D17269